Building a platform is a journey. As your requirements change, so will your APIs. When a company first starts out, its small applications require very little control. But as these applications grow, so will the organization’s business needs and responsibilities to its partners and customers. Along this growth path, companies can implement various tools and services, including API management and microservices, that will help them overcome current issues and enable to progress to the next step in their trajectory. But the key is to use each solution at the appropriate time in a company’s evolution – and not before.
Build a monolith first
Contrary to popular belief, monoliths are necessary to many companies’ development. This architecture pattern can offer benefits suited specifically to this unique and often fragile stage for an organization. The ability to quickly develop and implement a monolith allows you to get to market fast and start making money – without introducing unnecessary complexity. Putting you quickly into the market, monoliths enable companies to learn about the business domain gain profits without any operational overhead.
Often, organizations want to skip this phase and go directly to microservices. But implementing microservices too quickly is risky. Jumping into microservices before your company is complex enough can slow you down, moving the focus from the application to the implementation details. Martin Fowler has written about this and provided a nice overview:
“Codito,” a provider of industry-leading APIs for purchasing Microsoft Products, began its journey with a monolith. Codito customers can fully automate listing the product catalog, ordering products for home delivery, and receiving shipment information. On the input side, third-parties in charge of delivering packages provide updates to Codito via webhook about any status changes for shipments.
As a monolith, Codito was able to build an MVP very quickly. This allowed third-party shipment providers to immediately start integrating with them and opened the door for quick onboarding of its first customers. The money started coming in, and business was good. However, the architecture wasn’t ideal as security was low (requiring every consumer to comply with it), the app developer experience was poor, and there was no governance nor any API analytics.
Go beyond just APIs by building a governed API landscape
When facing hindered performance and limited visibility, companies can enhance insights and user experience by implementing Azure API management. With this approach, companies can make the internal API as secure as possible, while making it easier for Codito’s customers to use the API through API keys. Next to that, customers get a full developer portal that they can use to learn Codito’s APIs, with a single API hub for them all – even for other applications.
The most important aspect, is that Codito can decouple its internal APIs from what its customers are using, which gives the company flexibility to change its internal architecture (I.e., when moving from monolith to microservices). And these organizations can have visibility from the start with out-of-the-box API analytics, a built-in developer portal, consumer management, and centralized API hub.
When to move to microservices
As Codito grew, so did the company’s traffic. With more and more customers, Codito invested in transforming its MVP into a real product, and more developers onboarded.
Increasing traffic is good news, but at this more advanced stage, a monolith can’t keep pace with growing business. Codito’s monolith was too hard to scale as it was scaling the whole app as one block rather than as more fine, grained components, and the platform limited the company’s capacity with slow release cycles and compatibility with only one technology stack.
By migrating to microservices, companies like Codito can split their big monoliths into smaller, to-scale services. This separation allows for smaller teams that can be dedicated to one area or service and equips companies to use tech stacks that fit their needs. Microservices offers organizations easier scalability for individual services and enables quicker development for faster release cycles.
How to migrate to microservices
Once you’ve decided to move to microservices, you’ll need to understand that microservices are a journey in their own right. To reduce complexity and risk during migration, you’ll need to use a phased-migration approach:
- Split the monolith into multiple smaller services
- Ship them as individual containers
- Use as much PaaS as you can, until you reach a point of needing more control
As in Codito’s case, this phased approach allows a company to:
- Learn how to build, package, and run microservices, without managing cluster
- Leverage operational experience through Azure Web App for Containers
- Easily implement advanced compute runtimes like Kubernetes
Keep it logical with Azure API management
In our example, Codito starts with a “logical” separation. The first step is to split the monolith into multiple logical APIs that will be used by the customers, while in the backend, traffic is still routed to the monolith running on Azure Web Apps. From the customers’ perspective, Codito seems to be already running internally on microservices, but in reality the architecture is still calling the monolith as it was before.
This practice is ideal because it enables better product composition, platform comprehension, and user experience. Products are a great way to grant API consumers access, and companies can enforce security on some products while not on others. And customers aren’t negatively impacted as new consumers can better understand these updated platform components and any existing API consumers can be routed directly to the new service.
The next step is to call the new microservices and use A/B traffic routing to see if this new approach works, while still sending 50% of the traffic to the old monolith. Doing so allows Codito to verify functionality and overcome any issues before fully rolling out microservices.
Working with customers outside of the cloud
In today’s landscape of varying technology capacities, there are often some customers who aren’t yet using or can’t use cloud technology. This is obviously not ideal for many companies like Codito, whose platform sends requests to the cloud.
Azure Arc-enabled API management is a self-hosted version of Azure API Management, where it’s up to you to deploy, scale, operate, and manage the host. Managed from the cloud and with the same API & API governance across scenarios, this service can be deployed where you – or your customers – need it.
With centralized management in the cloud, Azure Arc-enabled API management be deployed to one or more gateways, which are federated to the cloud and require internet connection. Bridging the gap from customers’ limited technology to a more advanced architecture on Codito’s side, this solution provides a consistent API experience in Azure, hybrid, and multi-cloud scenarios. (To dive deeper into Azure Arc details, read the technical post from my colleague, Michiel Vanwelsenaere, “Running Azure API Management anywhere with Azure Arc for API Management.”)
For those Codito customers who wanted to use company’s services but couldn’t, APIM & Arc presented a solution that allowed them to run it all on their infrastructure – where they wanted.
Conclusion
Expanding to new services isn’t always the right solution for a company’s existing business needs. Instead, each company should focus on its current roadblocks and which services can help them take the next step on its growth path. As you’re building your own platform, keep these key points in mind:
- Neither monoliths nor microservices are evil – they each offer specific benefits suited to different phases in a company’s evolution. Let your company needs drive the evolution of your platform, using the API landscape that your platform requires and not going all the way unless you have a reason.
- Focus on your app, not infrastructure. Start with PaaS and evolve to Kubernetes and beyond as your traffic, performance, operations, and scale dictate it. This way you can continue to delegate operational overhead to your provider until you truly need to take over control. As you run your application(s) on fully managed platforms, you can reduce the learning curve for users.
- API Gateway helps your platform grow. This design allows you to decouple physical APIs from consumers and provide a consistent API consumer portal and gateway. Additionally, it provides the ability to manage API traffic and even use the approach as a protocol gateway.
Subscribe to our RSS feed