Featured Post

Event Sourcing Video from Michael Ploed

Event Sourcing I want to share a great video I found few days ago that describes very well what Event Sourcing is.

Tuesday, February 6, 2018


1. One codebase tracked in revision control,many deploys

Each app should have only one codebase used for different potential deployments. Each deployment of an app may differ in environments properties and capabilities.

2. Explicitly declare and isolate dependencies

You should not rely on system tool. Dependencies has to be declared into a declaration manifest so that any developers can use it via a package manager.
Managing application's dependencies with isolation and explicitly declaration means that you can deploy with a repeatable process.

3. Store config in the environment

Configuration has to be kept separated from code and credentials. All the code that is immutable among environments is to be consider the invariant part of you application.
A good practice is to consider configuration as supplied by environment properties or to fetch properties from a config server that provides properties depending on the target environment.
Another good practice is to keep a version control of your configuration.

4. Treat backing services as attached resources

A backing service is any service that your application uses to fulfill its functionality (another application service, a datastore, etc...).
Your application has to declare its need to use a service, and let the cloud to bind the declaration with the actual/proper values.

5.   Strictly separate build and run stages

A codebase has to be transformed into a production deployment. This can be done via three stages:
  1.   build: code repository is converted into versioned artifact;
  2.  release: push to cloud environment. Combining the output of build stage with the environment to produce an immutable artifact;
  3.   run: done by the cloud provider; a general pattern is to place your application is in a container based system.

6.   Threat logs as event stream

Logs should be threated a sequence of events emitted from an application in time-ordered sequence. This sequence can be collected together and routed to on or more final destinations for viewing or long-term archival.

7.   Execute the app as one or more stateless processes

Prefer stateless application: application that handles requests, without assumptions about memory contents. If necessary keep long state from a backing services. This means that the state should not be maintained in your application.

8. Export services via port binding

Cloud-native application is selfcontained and does not rely on external application server or a container. In this way via runtime port binding, it can act as a backing service for another application.

9. Concurrency

Scaling out in cloud-native applications should be done with a process model. Increase application size (CPU, RAM) to reach new capacity is an old model.

10. Disposability

Disposability is a capability of your application to come with a fast startup and shutdown. This capability facilitates fast elastic scaling and rapid deployment and all changes that can happen in a production environment.

11. Development, Staging, and Production as similar as possible

Keep the gap between development and production environment as small as possible.
A developer can write code in a way that the development team is always involved in solutions closed to production environment.

12.  Run admin/management tasks as one-off processes

One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same code and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.



No comments :

Post a Comment