Meet George, a software developer who works at TechXo Enterprises. A few years ago, he developed an online shopping platform on a monolithic architecture, where all the features (like product catalog, user authentication, shopping cart, and payment processing) are tightly integrated into a single codebase. As the ecommerce store’s popularity has grown over the last year, there has been an increase in the number of orders daily, and so has the need to scale it. Too much load makes the application slow and unresponsive, sometimes even inaccessible.
When trying to scale the application, George starts to face several challenges.
- Modifying the existing codebase and changing several parts of the application meant an increased risk of unintended side effects or breaking the existing functionality.
- Deploying a new feature in the monolithic application meant redeploying the entire application, which could result in downtime. An unexpected downtime would not only impact the user experience but also disrupt sales and result in revenue loss for the ecommerce store.
At this point, considering that the single-tenant, monolithic architecture running on-premise would not be able to scale and meet the requirements, George suggests migrating the eCommerce store to the cloud and replacing the monolithic architecture with microservices. This transformation can be done by adopting a strategic roadmap that involves retiring the existing legacy services over time.
Wondering why and how? Let’s explore it in this blog!
First things first: What is cloud-native?
Cloud-native is an approach to develop and manage applications by using the cloud computing delivery model that can run on any cloud platform. It enables enterprises to build and run scalable applications in dynamic environments such as public, private, and hybrid clouds.
These applications are built on microservice architecture, which is methodical in allocating resources to individual services used by the application. Microservices are exposed through APIs for interaction and collaboration. Each microservice goes through an independent lifecycle managed by Agile and DevOps processes.
Here’s an illustration showing the application architecture with multiple microservices:
Cloud-native application architecture and its pillars
Let’s now talk about the pillars of cloud-native technology:
So, why Cloud-native?
In addition to promising the ability to continuously innovate and drive team productivity while adapting to the dynamic requirements of today's digital landscape, cloud-native microservices architecture promises numerous benefits:
- Scalability: Cloud-native applications can easily scale up or down independently, making it easier to adapt to the changing demand. For example, if an application receives thousands of sign-ups at a particular moment, its authorization engine might get a hard hit. But only the affected microservices need to scale up instead of the entire application. This horizontal scaling can save costs on on-demand cloud resources.
- Improved time-to-market and agility: Microservices can be developed and deployed faster than monolithic applications, as smaller teams can work on individual services concurrently.
- Increased reliability and resilience: If one microservice fails, it doesn't necessarily impact others. Thus, it improves overall system resilience and reduces the risk of application-wide outages.
- Maintainability: Applications built on cloud-native, microservices architecture are easier to maintain, as changes to one service do not necessarily impact others, reducing the risk of unintended side effects.
- Improved security: Cloud-native applications benefit from the data security features of public cloud providers such as Azure, AWS, and Google Cloud. They offer additional security services and features, including localized data storage, access, and monitoring.
Approach to cloud-native application development
Here is the approach we recommend for developing or re-architecting cloud-native microservices:
- Existing systems: Start by assessing the existing technology landscape and breaking down the monolithic application into microservices.
- Cloud-native architecture: The next step is to select the cloud model (public/private/hybrid), cloud provider (Azure/AWS/GCP), and container platform that best meets to business needs.
Listed below is the step-by-step approach to cloud-native application development:
Case in point:
We are helping one of our clients develop a cloud-native solution based on modern technology. The application has a global reach and thus inherently requires governance, scalability, security, and regulatory compliance. Based on our approach, we opted to develop it as a multi-tier, multi-tenant architecture using scalable and reusable microservices and micro-frontends. We also aim to extend microservices benefits to the frontend and eliminate the pitfalls associated with bulky frontend monoliths.
We started the project by understanding the client’s requirements and defining the architecture with the following principles in mind:
- Minimal operational overheads of infrastructure management – Leverage managed services.
- Scalable and highly available architecture to ensure global rollout.
- GDPR Compliance and data residency requirements.
- Automate infrastructure provisioning and deployment for faster time-to-market.
- Extendible architecture to meet future integration needs.
Using AWS as the cloud service provider, we are building the ecosystem comprising of the following layers:
- UI Layer: The application frontend that uses Micro frontends architecture to build Single Page Application.
- API Gateway Layer: A reverse proxy to process concurrent API calls, handle CORS requests, throttling, authorization, and access control.
- Microservices Layer: The backbone layer contains independent, loosely coupled, reusable services that manage various domains. Having domains separated into microservices enables the application to adhere to a headless architecture. A message queue is used to communicate between different microservices.
- Data Layer: The layer responsible for persistent storage in the form of transactional data, memory data or static files (images, pdfs).
But, is cloud-native the best approach every time?
While it's true that switching to cloud-native, microservices architecture helps provide agility, scalability, and robustness, it is not the only silver bullet. Let's have a quick look at a few challenges of cloud-native architecture:
Complex infrastructure
One of the biggest challenges of building cloud-native applications is managing the complex infrastructure required to support them. Cloud-native applications are deployed and run on cloud infrastructure, including various services and technologies such as containers, Kubernetes, and serverless computing. Technologies often new and rapidly evolving make it difficult for developers to keep up with the latest best practices and technologies.
Additionally, cloud-native applications often require a high degree of automation and orchestration to manage and scale efficiently. It can be challenging to set up and maintain, particularly for small or inexperienced development teams.
Security concerns
Security is a significant concern when building cloud-native applications. Cloud environments are particularly vulnerable to cyber-attacks, and using complex technologies such as containers and Kubernetes can increase the attack surface.
To mitigate these risks, developers must take extra care to secure their applications and infrastructure. It can include implementing best practices such as least privilege access controls, encryption, and regular security audits. However, these measures require additional resources and expertise that may not be readily available to all organizations.
Lack of resources
Building cloud-native applications can require significant resources, including specialized expertise, tools, and infrastructure. Smaller organizations with limited budgets may find it challenging to invest in these resources and compete with larger enterprises.
Building cloud-native applications requires seamless collaboration and coordination between development, operations, and security teams. Without the right tools and processes in place, it can be challenging to achieve.
Cost overruns
The cost of cloud-native development is unpredictable. Even if there is usage-based pricing, it can lead to unexpected costs if there is a traffic spike.
As an example, Amazon Prime Video, one of the world’s largest streaming services, recently reported that they moved their service quality monitoring application from microservices to monolith architecture. The tool was set up to monitor every stream viewed by customers and analyze the quality of audio and video streams in real-time. As the number of streams on the platform increased, they discovered numerous state transactions occurring every second of the stream.
These transactions included a high volume of read and write operations to S3 buckets, as well as communication between AWS Lambda and S3 Buckets. As a result, the cost of the service became expensive. Hence, they rearchitected the infrastructure and moved all components into a single process to keep the data transfer within the process memory. They claim that the migration from microservices to monolithic architecture helped them not only increase the scaling capabilities but also reduced their infrastructure cost by over 90%.
Conclusion
So, while cloud-native architecture may bring numerous benefits, its complexity makes it hard to maintain performance, and security. There is no one-size-fits-all solution in software development. We recommend businesses to carefully evaluate the trade-offs between microservices and monolithic architectures for each component of a system to deploy the most appropriate architecture for their applications.
Let’s connect!
Like many others, are you too confused about adopting cloud-native architecture? We can help! Get in touch with us today!