One week ago, I attended a workshop at the campus of Microsoft France. The workshop presented the principles of Microservices and containers such as docker, Kubernetes, this amazing training inspires me to write this blog post where I’ll resume and explain the principles of each concept.
The first part of the workshop was just recalled the cloud basics. Then dive into the design principle for the applications before deploying with microservices in Azure. The main part of presentation regarding the principle of microservices and finally share a real-life example on GitHub.
Recall General Cloud Computing Service Models
Cloud is ‘internet’, cloud providers provide different ‘services’ via the cloud. There is general build into 3 types of cloud computing service models: IaaS, PaaS, and SaaS. Each service offering provides a different level of virtualization and management responsibilities.
Caption: different cloud computing service models from Microsoft’s documentation
IaaS: Infrastructure as a Service
IaaS service model provides generally the capability of infrastructure level to the users, the cloud providers managed the hardware and infrastructure such as virtual servers, storage, networks, connectivity, operating systems and other fundamental computing resources, users should manage them with administration works such install the patches, updates, configurations etc. One of best examples of this model is the virtual machine in the cloud.
PaaS: Platform as a Service
The PaaS services model provides the capability of comprised of deployed and configured IT resources. Users don’t need to care about infrastructure level and even the administration work they faced when they’re in IaaS model. It provides the environment with the specified runtime, what users need to do is to focus their work on the application level.
SaaS: Software as a Service
Compared to PaaS, SaaS has a more advanced virtualization level which provides widely accessed over the internet and directly used by users. The most common example is Google’s G Suite and Microsoft’s Visual Studio Team Services ( which is also known as visual studio online ).
Further ‘X as a Service’ in the cloud
Based on these models, there are also some extension concepts which is known as “X as a service” : such as DaaS ( Database as a Service ) , CaaS ( Container as a Service ), MaaS ( Messaging as a Service ) , IDaaS( Identity as a service ) and DRaaS ( Disaster recovery as a service ) etc.
Before deploying your applications with Microservice on Azure, there are some prep works while designing or recast your existing applications. Let’s why we’ll start to explain what is the real ‘ cloud-native ‘ applications.
The 12-factor app
The 12-factor app methodology was first presented by Adam Wiggins circa 2011. It addressed to design and build software as a service application which is with portability and resilience when deployed to the web.
This methodology is kind of mythology to build SaaS app and cloud-native application, the principles generally are :
- Allows to install and prepare the related environment with automation methods such as Azure Automation on Azure or AWS Opswork, by using a declarative format to produce an identical result ( always reached the desired state )
- Be able to run in different OS environment with maximum portability
- Loosely coupled so that can be deployed in the cloud
- The development environment and production environment should be identical ( only allow to target to a different database but the structure remains the same )
- Allow continuous deployment so that to maximize the agility of deployments
- Highly scalable when peak time without changing the configuration tools
4 reasons to cut traditional application as a microservice application
To resume, there are 4 main reasons to recast or start at design phrase to apply the principle of microservice architecture :
- Independence modules so that each can scale at their own space
- Possibility to use of different technologies in the same application for example, in the same application, it can exist the RESTful API service developed both in node.js and in .NET web API.
- High backward compatibility. Client-side applications evolve at their own pace
- Easily managed the conflict of dependencies.
Caption: the difference between the application in monolithic architecture from microservices from https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices
Before starting build microservice :
To go further than theory, in this context, the modern cloud-native applications expect to deploy with microservice architecture can be managed in a versioning control tool such as git and following the principle of ‘ a codebase = 1 repository’, and should isolate and declare the dependencies and system in an explicitly independent way. It will facilitate the maintenance and administration task.
At the same time, the codes should be separated with the configuration file, that means should pay attention to that: code should be only with variables but not the application or environment settings).
The application should be strictly stateless and share nothing with each module. Generally, the front site does not store any data, so the data is always in the backend, and maybe exchange information by middleware such as implementing a RESTful API.
Each application must be autonomous in a ‘ self-contained’ way, so that each type of work by deploying one application, so general idea is ‘ one process one microservice’, the advantage of this idea is microservice can be well structured and we can add or delete processes in an easy way, during the peak time, we can multiply the process by multiple the instance, during downtime, it is easy to realise rapid stop and start, so that the offline service back to normal rapidly.
Checking the integrity of event and flow logs will be an important part while implementing the monitoring strategy. Since each microservice is an independent part but act as a whole system when they’re working together, the strategy to implement the logs will be based on the event. Microsoft Azure provides log analytics services and other metrics services while monitoring each microservices.
The principles of microservice on Azure :
As Microsoft defined microservices architecture as a whole system contains a collection of small, autonomous services. Here are some principles while deploying microservice on Azure:
- One App server per microservice
- Each microservice has its own data persistent store ( backend side )
- Each microservice has its independent life cycle
- No dependency on other modules
- Small and numerous as possible, facilitate the fast deployment in a more frequent way
- Strongly loosely coupled, as a small elastic unit within the distributed system
- Isolation from the resources of applications
Microsoft documentation also provides their official guide to help user designing, building, and operating microservices on Azure, here is the link: https://docs.microsoft.com/en-us/azure/architecture/microservices/index
In action: real-life scenario regarding microservice on Azure
One of the most interesting parts of the workshop is to analyze a real-life example which builds with microservices on Azure, which is Microsoft eShop Container, this is a microservice architecture based application using .NET Core and Docker. In this project, it contains different types of microservices :
Caption: different types of microservices in eShop on containers example
This example was published on GitHub with the below link: https://github.com/dotnet-architecture/eShopOnContainers. The principles of this example will be explained with a simple example in another post: building microservices on Azure in upcoming days.
If you’re a .Net developer or anyone who is experienced in Microsoft technical solutions, you will definitely benefit from one excellent book which is recommended by Microsoft regarding microservice: .NET Microservices Architecture for Containerized .NET Applications, it explains in detail how to develop the microservices architectural style, here is the link to download it: https://aka.ms/microservicesebook
“organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – By M. Conway
( Conway’s law in 1968 from http://www.melconway.com/Home/Conways_Law.html )
Next steps :
This post resumes the cloud basics and related concepts regarding microservices, actually, MS workshop has another part regarding dockers, containers solution on Microsoft Azure, DevOps and especially the principles of Kubernetes which I’ll present in my next post.
Personally, I enjoy a lot the latest deployment methods and creative style while designing the application architecture brought by cloud computing. As cloud computing is boosting our business today, I hope the new normal will help us create more application with portability and resilience in the cloud. Let’s stay tuned!