It’s not that hard to think of a state-of-the-art architecture, designed to continuously evolve with changing demands, changing expectations, and changing technologies. You just need to disentangle your software into microservices, make them event-driven, run them in auto-scaling and auto-healing containers on top of a software defined network, put API management in place and fully automate your deployments.
Preferably, you practise blue-green deployments, A/B testing and circuit breaking to maximize your resilience. And then you’re pretty much set, and the agile dividends will start to pay off. You can move freely, adapt quickly, and hit the highest quality standards at the same time. Easy enough, right? Look at the cloud providers. They practice microservices on a much bigger scale and don’t need any maintenance windows to keep up-to-date. Just an incidental server restart, and presto! Job done.
Well, in reality, there are a couple of bottlenecks to overcome.
If you have to believe the management gurus, the startup culture is conquering the enterprise. Small, autonomous teams are coming to the rescue of large, lethargic companies. Everything is changing. In IT, agile development teams have been proven successful in modernizing development practices, however, they also tend to face the operations wall. No offence, but embracing change has never been a core value for ITIL-driven service management organizations. Hence, we’re coming up with DevOps teams, essentially adopting much of the operational responsibility by the product owner. This includes change and configuration management, problem management and application management, amongst others.
Now, we’re facing a next hurdle. DevOps teams can only independently manage the stuff their product owner owns. That’s why we are currently rethinking enterprise governance, enterprise integration and enterprise data warehousing. Because everything you manage at the enterprise level tends to become a bottleneck for change. And because changing those enterprise systems is risky, they are mostly rarely updated, if ever. But that’s a topic for another blog post.
You may have noticed WSO2 is currently offering a micro API Gateway, and a micro integrator. Clearly, this hints at the microservice architecture style, which highly resonates with agile teams. Even a micro-firewall is a thing now. Now this may come across as a silly marketing effort, but I believe it’s not. It’s all about empowering agile teams in their efforts to increase their autonomy responsibly.
Look at the microgateway. This is designed to manage the incoming API traffic to protect the backend system from overload. It nicely fits in a microservice oriented architecture, like the one in the diagram. Here, you have four different systems, managed by different teams, and owned by different product owners. Each system is built from a number of microservices and a microgateway. The intra-system communication is unrestricted, typically on localhost, otherwise over mutual TLS. All the microservices have a network endpoint, but to connect from outside you have to pass the microgateway first. This effectively acts as an anti-corruption layer, protecting the system from garbage coming in, and from accidental message floods. The microgateway may simply run as a sidecar on the localhost, to minimize latency. Note that not every microservice is necessarily exposed on the gateway.
At the enterprise perimeter, there is an additional gateway, to guard the foreign systems interacting with the internal systems. This gateway checks subscriptions and their related service levels, collects monetisation information, and may enforce access control policies. As a rule of thumb, the perimeter gateway enforces demand-side policies, whereas the microgateway does the supply-side policies. Makes sense, right? Additionally, a software architect can also nicely separate his system-level APIs from his business-level APIs.
Similarly, other enterprise systems can be broken up into micro-equivalents, if necessary augmented with a joint system having a much smaller scope. That’s what is takes to get agile, and that’s how WSO2 has got you covered. You can go all the way in your microservices transformation, if you prefer, but of course you can also mix and match to best suit your own architecture. And you know, we love to design these solutions tailored to your particular needs, or review a design you may have in mind. Just reach out. Now the wait is for someone to launch a micro resource planning solution.