Redefining Cloud Native
In 2010 Paul Fremantle (WSO2 CTO) has defined and introduced cloud-native [1]. Within these 8 years it have evolved into different space. Microservice Architecture, DevOps, Containers take a major part of the cloud nativeness in modern world. They all bond together. Synergy of all of these powerful technologies will make your application more resilient, scalable with greater agility and portability.
Sustainable business requires an alignment between business and IT. Agility and rapid application development are key indicators of an organization that is prepared to sustain in short term business well as long term business. Cloud nativeness provide greater agility, resilience, and portability across cloud environments. Cloud-native should not be an afterthought, cloud-nativeness should come from product architecture itself.
Let’s look at what characteristics Containers, MSA and DevOps are bringing into the “Cloud Native” world addition to what Paul has defined.
Fast boot
Align with the MSA, services are going to be micro. Single service will handle dedicated smaller business problems. It will be deployed into its own container runtime. Compared to VM overhead, container overhead is very minimal. Considering all the facts single service should be start less than 1 to 2 seconds.
Smaller size
Since services are micro, they should be less than the size of 50MB. When a rolling update takes place, these microservicers should be able to populate across the runtime clusters at fast. If services are distributed as container image, they should be able to pull within seconds.
Low footprint
Services should not take more than 100MB of memory. Within the allocated memory they should be able to handle expected load and scale fast in case of load increased.
Stateless UI
When it come to scaling UI apps, most of the cases we have to use session aware load balancing. Mainly because, majority of UI apps are stored user details in session variables to identify the users. But this is not going to be scaled. Only workaround is either to do session aware load balancing or session replication when scaling. But if we can use token based authentication and authorization, requests can be routed to any node without been intelligent in the load balancing layer.
Local cache
Distributed cache mainly used to state synchronizing among all the instance in a cluster. When application is scaling this will not be as it is. If we use local cache instead of distributed, first request will be slow for a given instance. But most cases we can live with that. Cache revocation and update should be handled separately when a cache timeout not enough to cater the requirement. Ideally we should minimise usage of distributed cache.
Auto discovery
With the MSA we can expect considerable number of microservices in an application. These microservices can be distributed over multiple hosts. They can be scaled up and down depending on the load. These microservices should interact each other. Built-in auto discovery mechanism is very helpful in these kind of dynamic environments.
Independent scalability
There should not be a hard wiring among different services. They should be communicate via loosely coupled channels. If we can make them self sustained, that would be the ideal.
Configurable through environment variable
We should minimize the config points. Each service should be able to run with default config. If we want to introduce configs, they should be easily populate via like environment variables. This is very importance when you decided to use containers to deploy these services.
Infrastructure as a code
Last two decade or so, we have delivered softwares as separate artifacts like a zip file etc. In the production environment, Ops need to be installed all dependances and then configure product artifacts in the production servers. Main problem in this model is developer used deterrent infrastructure (different OS version, different libs, different dependencies etc) for development stage and cloud not be identified issues that could be arrived in production. Ideal solution would be to pack/bundle all infrastructure artifacts which are used in developer environment with the product as product delivery.
Immutable
Immutability is an important concept in the operational perspective. It gives hassle free upgrades/updates and the rollback. Immutability can’t be achieved only in operation if product architecture does not support.
Summery
Microservice architecture, DevOps and Container are introduced very valuable concepts and best practices into software industry. These have taken a major part of the cloud nativeness. It will provide greater agility, resilience, and portability to product to run across cloud environments. To get all these benefits, cloud-native should not be an afterthought, cloud-nativeness should come from product architecture itself.