Unveiling MACH: Exploring Micro-services with GCP — Edition 1
Introduction
The most predominant and glorifying architectural design for large scale and complex applications in the modern age is MACH. MACH is Micro-services based, API-first, Cloud native and Headless. Micro-services was already a buzzword in the industry and with the adoption of cloud based applications, MACH has got its well-established place in the minds of software architects and engineers.
In this blog, I am going to demystify MACH architecture and how it can be implemented on Google Cloud Platform a.k.a GCP.
MACH is a software application architecture which suggests breaking down complex applications to multiple smaller components or services. It targets scalability, flexibility, and agility by segregating applications into independent and loosely coupled services which are owned by different smaller teams. Lets try to understand MACH in detail before we actually implement it on Google Cloud.
Micro-services based: Micro-services are business oriented, independently deployable and maintainable pieces of code which run on their designated hardware resources and are managed by a smaller independent teams.
API-first: API first means that the micro-services are designed by targeting the inputs and outputs required for the services to communicate with each other rather than focusing on the code as we do in a monolith design. In short, API interfaces before coding!
Cloud-native: Cloud native is a term used for applications or services which are developed in cloud and uses it full capabilities i.e scalability, availability, reliability and fault tolerance.
Headless: Headless means that services should be business-oriented not front-end oriented. Concept of headless ensures that engineering efforts are not focused on UI but on business needs while designing micro-services.
Monolith Architecture
Before we move on to micro-services and MACH, lets understand its counterpart — Monolith Architecture. A typical monolith architecture would look something like this.
In a monolith architecture, the entire application or codebase is merged together where different subdomains(i.e orders, shipping, product inventory etc) are tightly coupled. Different teams have to work together without any independency and a lot of efforts are required to write and manage code. Continuous integration and deployment is hard to achieve and all the teams have to work on a single technology stack.
However, with all of these drawbacks, a monolith is not necessarily all bad. Many factors need consideration before determining which architecture is suitable for your application. A monolith is simple, cost-effective, and provides a straightforward development and deployment process. It may be the right choice for smaller projects or when the development team is relatively small. Additionally, debugging and maintaining a monolithic system can be simpler compared to more complex, distributed architectures. The key is to weigh the pros and cons based on the specific needs and scale of your application.
Microservices on Google Cloud
As discussed earlier, micro-services are smaller, independent components. These services can be developed using entirely different tech stacks, providing development teams the liberty to work with any programming language and framework they prefer. Moreover, since these services are loosely coupled, they operate with individual tables or databases, which might also be loosely coupled or eventually consistent. While micro-services offer flexibility and scalability, it’s essential to carefully consider the complexity and potential challenges associated with managing a distributed system.
Messaging using Cloud Pub/Sub
Effective communication is crucial within the micro-services architecture. Services must communicate with each other and application clients, necessitating a specific type of messaging and inter-process communication. Fully managed messaging services like Cloud Pub/Sub or self-managed Kafka on GKE cater to the need for a robust messaging system. Cloud Pub/Sub, being a fully managed cloud-native service, stands out as an excellent choice due to its high availability and scalability features.
Inter-service Communication using gRPC or Apache thrift
Typically, service to service communication is not done in form of REST API calls as rest is slow and inefficient when multiple requests and many responses are to be handled within micro-service architecture. gRPC uses Protocol Buffers(protobuf) as serialization format which makes it efficient in speed and size. gRPC is developed by Google and a lot of Google Cloud Services uses gRPC internally to communicate. Apache thrift is another framework used for service to service communication that supports binary protocol, JSON and more. gRPC is a most prevalent in the industry as it is easier to use and more efficient than apache thrift but a choice can be made between these two as per the requirements of your micro-service architecture.
Cloud SQL or Cloud Spanner for micro-services
Micro-services can have database per service or privately accessed tables per service. It depends on the requirements and type of service. Sometimes services need to share a single database to make sure easy access of data. However, a database per service is advisable to ensure proper segregation of services’ data. Cloud SQL and Cloud Spanner are two choices in hand while designing service architecture. Cloud SQL is a fully managed, regional database service offering by google cloud. It is highly available and reliable database management system deployed on cloud. Cloud Spanner, on the other hand is global, distributed and highly scalable database service. It can cater the need of a highly available and robust database which has to manage loads of read/write operations.
API Gateway on Google Cloud
Typically, in a micro-service architecture, web applications or mobile applications are the clients of micro-services. These apps usually rely on REST endpoints to consume these services. An API gateway is a single point of contact for any external client which then internally calls relevant services to provide the required data to the client. Using an API gateway creates an abstraction layer for the micro-services for the clients. Google Cloud provides API gateway which can be used to create this additional layer of abstraction and security.
Google Kubernetes Engine or Cloud Run for deploying micro-services
The most important part of a micro-service architecture is to deploy and run services so that they can be used. This takes us to the step where we decide on how to deploy these services for production use. Services can be deployed on a VM, Cloud Run or a GKE cluster. Cloud Run is a fully managed, server-less engine to deploy apps and services. It is a best choice for the services which need autoscaling capabilities and can be assumed to have a lots of utilization and traffic. Services can also be deployed on a GKE cluster. It is easy to manage and package services with all of their dependencies using containers
Cloud Logging and Monitoring
Last but not the least, no architecture is complete without proper logging and monitoring system in place. Not to worry if you are planning to set-up your micro-service architecture on Google Cloud. Cloud logging is a cloud based tool to store, search and explore all the logs at one place. Cloud monitoring is another tool which can create interactive dashboards on alerts for dev teams to check and analyze resource utilization and much more.
In this blog, we saw an overview of a typical MACH architecture. In the upcoming blogs, we are going to deep dive into different aspects of a MACH architecture which were discussed above. So, join me on this journey of exploring and understanding bits and pieces of MACH.
See you all soon in my next blog!
