Since few months I thought to write about Cloud-Native. Is it just a buzzword or it truly worthy jargon ? Believe me It is not just a buzzword, It’s a new Architectural style to build scalable, complex and microservice based applications that are easy to deploy, automate and maintain.
It helps business to service their customer with fast to market releases without taking a downtime to release a new feature or product or service.
Well will look into all terms like what is mean by Cloud-native and microservices. Together its a new way to build large scale complex applications with modern way of software development trends, best practices and off course Cloud Infrastructure.
Well lets first explore what are the best practices for designing microservice based applications, why microservices and then how it leverage the cloud.
What is Microservices: a architectural style to build modern applications. Modern means the application can cater any request from different client like Web, Mobile or from another service in seamless manner.
- Its a distributed small set of independent services, that interact with each other to full fill user request and form the entire application. The small groups can be created base don Business domain, functions or features. for example, in case of e-commerce website there can be different microservices like authorisation, product listing, rating, matching or similar products, pricing, discount etc.
- every microservice developed independently and autonomously means each microservice having its own codebase, deploy strategy and database and so can be developed in parallel.
- In short microservices are self-contained, isolated from each other though they form a complete application by communicating to each other through different protocols like HTTP/HTTPS, WebSockets or Messaging (like event bus, AMQP etc)
Why Microservices: by knowing above characteristic of microservices the answer is self explanatory
- Scalable Independently: yes as they are isolated in nature, they can be scalable as single unit instead of scaling entire application.
- Independent lifecycle: each microservice is independent unit of program/application that can be amended, turned down and deploy without affecting risk to entire application. So having multiple release cycle and no dependencies on other application units to rollout the feature to market.
- in more sense the microservices are loosely coupled.
So how you will design microservices, what are the decision factors and best patterns. So lets have a look at 12-factors (Twelve-Factor)
So 12-factors are widely accepted set of principles and best practice that if adheres they act as a solid foundation for building cloud-native applications.
|1||Codebase||One codebase for each microservice having its own repository – yes it will end up in multiple codebase that’s how distributed systems works. Note: Multiple apps sharing the same code is a violation of twelve-factor. The solution here is to factor shared code into libraries which can be included through the dependency manager (#2 principle).|
|2||Dependencies||each microservice explicitly declare and isolates its own dependencies i.e. set of require libraries or other services etc.|
|3||Config||configurations should be externalized like maintained as environment variables, properties, vault etc.|
|4||Backing Services||there should be no distinction between local and third party services. example Database, caching services, SMTP or AMQP, AWS S3 should be treated as attached resources to microservices.|
|5||Build, Release, Run||Strictly separate build and run stages i.e. having separate CI-CD pipelines and enforce separation across builds|
|6||Processes||stateless and shared nothing, any data that needs to persist should stored in backing service mostly database. Note: Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon.|
|7||Port Binding||Export services via port binding, each microservices completely self-contained. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.|
|8||Concurrency||Basically services should scale horizontally (and not vertically i.e. adding resources to same machine) The share-nothing, horizontally partitionable nature of twelve-factor app processes means that adding more concurrency is a simple and reliable operation.|
|9||Disposability||Maximize robustness with fast start-up and graceful shutdown of resources i.e. elastic scaling|
|10||Dev/Prod Parity||Keep development, staging, and production as similar as possible – helps in continuous deployment with minimal or no deviation while deploying from development environment to production.|
|11||Logging||Treat logs as event streams – app should not attempt to write to or manage logfiles. e.g use Fluentd, Azure monitor or AWS LogTrail to manage the logs.|
|12||Admin Processes||Run administrative/management tasks as one-off processes. Tasks can include data clean-up and pulling analytics for a report. Tools executing these tasks should be invoked from the production environment, but separately from the application.|
This is how 12 factors helping in designing modern cloud-native application. In next part of this series will look into more cloud-native terms related to microservice patterns, containers, their importance and container orchestration, why and how – in short my fav topic Kubernetes.
Off course will try to put some working example if possible or you an always reach out to me though comments.
Take Care and Stay tuned…