Skip to main content

Not all Ps sting

 

If someone meant to say Ps and pronounce it Bees. would this confuse you :).

Ps is for the P that is the start of Properties and Practice
Each application should have some properties and follow certain practices.

Properties:

Below are 5 properties we should try to have in our application with a small description of how to include them

  1. Scalable, Scale => Increase workload (horizontally scaling)
    1. Statless, no state should be shared among different application instances, 
    2. Concurrency, concurrent processing = Threads.
  2. Loosely coupled, decompose the system into modules, each has minimal dependencies on each other "modularization", encapsulating code that changes together "High cohesion". 
    1. API first, Interfaces, implementation can be changed without affecting other application. favor distribution of work across different teams. 
    2. Backing Services, "DB, SMTP, FTP ..." , treating them as attached resources, meaning they can easily be changed.
  3. Manageable, changing the internal state and O/P via external I/P,  Also regarding updating the application while keeping the overall system up and running.
    1. Configuration: aspect that changes during deployment should be kept outside the app codebase, recommended to be stored as environment variable within environments.
  4. Observable, infer the internal state through external O/P, ensuring that every component provide the correct data.
    1. Logs, treating logs as event stream. Log aggregator for fetch/collect logs to be available for inspection.
    2. Telemetry data, matrices, traces, health state and events. 
  5. Resilient, Failure is not cascaded (Isolated), a system is considered resilient if it provides its services even in the presence of a fault. 
    1. Disposable, can be started/stopped at any time, designed to start quickly.
Practices:
Below are 6 practices we should follow
  1. One CodeBase, 1**1 correlation between application and repository, each application is tracked in its own repository.
  2. Administrative Processes, handled as small standalone services, "DB migration, Batch job, maintenance job ..." should be tracked in revision control.
  3. Dependency management
  4. Design, Build, Release & Run, each release is immutable and should be uniquely identified.
  5. Environment parity
    1. Time gap, reduce the period between when a developer writes a code to when it is deployed.
    2. People gab, embrace DevOps culture, improve collaboration between teams.
    3. Tool gab, same type/version should be used in all environments, keeping environments as similar as possible.
  6. Port binding, Self-Contained, containers, application is self contained. translating request from public endpoint to internal port bounded service.
Notes: 
 - One application can become the backing service of the other.
 - Admin code better to be shipped with application code to avoid sync issues.
 - Working with modules increase flexibly as each will evolve independently. 

References:
 - Cloud Native Spring.
 - 12 factor

Comments

Post a Comment

Popular posts from this blog

The post-office & the postman

If we were to talk about old messaging system where there exist post-office, postman & mailbox. each component had its own functionality that we looked for when trying to visualize how those component where to interact in a computerized version. Simple scenario: Mail is added in mail box Postman arrive pick mails from his area mailboxes and take them to the post-office. Post-office organize mails by areas. Postman takes mails related to his area "distribute it in mailboxes". A person can go to post-office and  pick his own mail "in case of failure or wishes for early delivery". Mapping in a computerized version: Scenario: Observer design pattern which can use push or pull scenario, to inform those whom are registered for an event about its occurrence. Component: Post-Office = Message-Broker Post-Office-Box = Message-Storage-Validity Mailbox = Topic/Queue Postman !!! where's the postman ? Apache kafka act as a message broker which d...
Post a Comment
Read more

String literal pool

I'm used to use String .format() when constructing a SQL statement, and a friend I knew likes to concatenate saying :"it's more readable to me". So String Objects are immutable, meaning that once they are created, they can't be altered. Concatenating 2 strings doesn't modify either Strings instead, it creates a new String "old ones are added to the string pool". String literals always have a reference to them in String Literal Pool, therefore not eligible for garbage collection. to concatenate use StringBuffer (Synchronized) or StringBuilder (not Synchronized) As both uses an internal array "so that new String Objects are not created". String literal Pool : String are stored in pool and before creating a new string  literals, compiler checks if such string already defined "used to optimize and save space". String literals : a sequence of characters between quotation marks. 
2 comments
Read more