Better suited to cloud deployment and agile software development, use of a microservices architecture is spreading from savvy technology companies to mainstream enterprises.
I’ve recently interviewed a dozen technologists (eg, architects, engineers) who are using a microservices architecture for their applications.
From the front lines, and with the permission of my client Lightbend, here are five non-proprietary observations on the move to microservices.
1. Business imperatives, not just buzz
Interest in microservices has surged over the past two years, as shown in the Google Trends chart above. Yet, for the businesses adopting a microservices architecture, real business imperatives, not buzz, are behind the change.
I found three imperatives for using a microservices architecture to modernize legacy applications:
- Adapting to delivering software as a service (SaaS) rather than on premises or physical delivery;
- Inability to support surges in business volume with the synchronous architecture of a legacy app that is running out of threads; and
- Increasing the velocity of software development and reducing risk with smaller, more frequent deployments.
2. Your micro is my macro
Half of the technologists I interviewed wondered aloud how micro a microservice should be. Several participants used adjectives like “coarser grained” or “medium size” to describe their microservices implementation. One architect told me he made this compromise to avoid the rigors of an asynchronous event-based architecture which could support having “a thousand microservices in [a] system.”
3. The demands of velocity
Increased velocity is one benefit of developing hundreds or thousands of microservices with small, two- to six-person teams. Yet so many moving parts does increase complexity.
- For one participant, this complexity arises throughout development, QA, and production, whenever the latest versions of all a system’s services have to be assembled.
- The team at one e-commerce site has struggled with fixing broken services. Who’s going to fix the problem when both members of a two-person team have joined another team, or left the company?
- Finally, most of the technologists I interviewed brought up the difficulty of monitoring a multitiude of microservices, which is exacerbated by continuous delivery as teams regularly deploy new versions of their services.
4. Platform heterogeneity
As small, freestanding applications, microservices allow developers to choose the best tools and technologies for the use case, or at least their preferred ones. In the organizations I interviewed, language and persistence varied the most.
- While Amazon Web Services (AWS) offers five pre-configured database services, instances of MongoDB, Postgres, and Cassandra had all been set up by teams I interviewed who’ve deployed their applications on AWS.
- Some organizations are concerned that heterogeneity can go too far, making it hard for people to switch teams or have enough expertise in-house to look after a critical component. Several of the organizations I spoke with have responded by establishing an “official” architectural standard or a recommended list in the form of an internal tech radar.
- Monitoring and continuous delivery are two technologies which were standardized at most organizations I interviewed. However, developers were still free to implement their own monitoring stack in parallel with the standard.
5. Operational support
Half the organizations I interviewed deploy their microservices applications in the cloud, and all but one of those take the “you build it, you run it” approach popularized by Amazon.
For most of them, this works because they use pre-configured AWS technologies to keep operational support low. But when AWS’s technologies didn’t satisfy the use case, the technologists I interviewed were quite vocal about the pain they’d experienced, and had experimented with alternative clouds and serverless offerings like AWS Lambda, Google Cloud Functions, and Azure Functions.
The lines between Development and Operations teams are blurred for the organizations which deploy microservices on premises. Developers not Operations has experience with the new microservices application platform, while Operations is still responsible for all deployed applications, and is expert with legacy systems. Organizations I spoke with bridged this gap by directing the microservices Dev team to coach their Ops team counterparts, acknowledging it shifts developers’ attention away from tasks of business value.
Related Posts
Sales Win Loss Analysis: Why Data-Driven Leaders Are Leveling Up
Sales win loss analysis helps leaders make data-driven decisions. What’s working and where can we double-down? What isn’t working, and how do we fix it?
Win/Loss Analysis Reports: 3 Things You’ll Learn
Which aspects of your product offering and buying experience are helping drive sales? And which aspects are hindering sales? This is what enterprise and mid-market software companies often struggle to understand. A good win/loss analysis report will provide the answers to these questions.
Three Reasons Sales Leaders Want Even More Data About Their Buyers
While B2B sales teams are literally swimming in data, it’s not enough. Data-driven sales leaders are using input directly from buyers to find new ways to improve win rate and lead with conviction.