We’ve got the engineer, the conductor, the brakeman, and all of the commuters (business people) on the train – we’re almost ready to go. In my previous post, I wrote a lot about team structure; this entry is going to take inventory of the technological capabilities that power a microservice architecture.
From steam engines to bullet trains: leveraging prior innovation
The early adopters of microservices had to clear the land, lay the track, and build their own trains in order to reap the benefits of their new approach. Netflix, for example, worked on deconstructing their monolith over 8 years! However, companies just getting started on their microservices migrations can take some shortcuts confidently based on the experiences of these pioneers.
As a followup to the seminal post that popularized microservices, Martin Fowler published another post on his bliki describing his view of the prerequisites for microservices, namely: Rapid Provisioning (Cloud), Basic Monitoring, Rapid Application Deployment (CI/CD), and a DevOps Culture.
Fowler’s list is simple, elegant, and specific; I also think it could easily be misinterpreted. These capabilities are necessary, but with five additional years of hindsight, I believe there are many more capabilities that can help organizations accelerate their move to microservices; especially in the area of running microservices. For safe passage, I offer the following list of assets to put in holding before leaving the station:
- A layered security platform, including a) capabilities in and around authorization, authentication, and identity management; b) protections from bad actors and other threats; c) capabilities to interrogate the identity of the requestor and pass to the services (within and across heterogeneous architectures) that handle the request.
- Routing, policy enforcement, service mediation, and discovery (service advertising for registration/deregistration) capabilities because of the nature of a dynamically changing set of ephemeral services.
- Persistence and caching services available to microservices through a highly available, optimized, low-latency API that can cater to a variety of needs via relational storage, object storage, K-V, Event Sourcing, Event Messaging, etc.
- Analytics services – both business and operational KPI measurement to help guide investments.
- Complete application network observability across and beyond the microservice landscape. This will inform advanced monitoring systems managing and including end user experience, application performance, event monitoring, and distributed audit/operational logging & tracing.
- A runtime plane where scaling and scheduling services are declarative.
- Developer tools around configuration management, test automation (consumer-driven/side contract test, service component test, etc.), service virtualization, and SDKs.
and, arguably most importantly,
- A platform that drives self-service discovery and consumption of assets already in the ecosystem.
New train, same stations: leveraging existing technologies and assets
Innovation “improves on or makes a significant contribution to an existing product, process, or service” to bootstrap the development of new experiences that the market demands. When MuleSoft talks about reuse, we’re not talking about an API on a developer portal, or a canonical model in an MDM, or a trait for a mobile device, or a fragment that can be used across multiple API’s driving consistency; MuleSoft is speaking about all of that. Acceleration comes in the ability to build new experiences by composing and building on assets that were built by those before you.
To state this another way, Sam Newman’s article on patterns offers a similar opinion of reuse. Newman argued for an enterprise API model that focused on the needs of the client and its affordances; reusing the things that are common while iterating for the things that are not. In other words, the needs of a mobile device (such as pagination, battery life as a function of number of calls required, and unreliable networks) are different than the needs of a browser experience (which benefits from caching, redirection tolerance, and screen size to name a few). MuleSoft’s API-led connectivity approach inherently offers the capability in the platform to scale this architectural pattern.
Microservices are about velocity, and it may seem like I’m ignoring the traditional IT paradigms around efficiency and stability. I am. Well, I have been because speed should be the point on the horizon that we never take our eye off. However, we can’t ignore the others. In my next post, I specifically talk about how to balance velocity with efficiency and stability.
Matt McLarty contributed to this post.
