Microservices are the hottest topic in software today, and for good reason. The application architecture, pioneered by Netflix, breaks a single large application executable (a.k.a. monolith) into multiple chunks of functionality known as services. The architecture has many benefits, including helping you design better applications, doing more thorough testing, serving as the basis for cloud-native applications, and even transforming the relationship between development and operations from a finger-pointing blamefest to a collaboration based on container lifecycle management.
With those benefits on tap, IT organizations are all agog about microservices, and development tool vendors are salivating at the potential opportunity to offer products to a market hungry to move to this new approach to application design and operations.
That's where it gets sticky. Too many vendors are proclaiming that they’ve got the microservices solution, though their products deliver little to none of what’s required for a full, end-to-end solution. Most of the time the “microservices” product is little more than an existing product repositioned in the hopes of increasing prospect interest. This type of activity is so common that a phrase has evolved to describe it: brochure engineering.
Beware when you hear these three egregious vendor claims:
Lie #1: “We’ve got a framework”
Vendors claim that their frameworks can easily enable different development groups to work separately but have their individual components "automagically" connect and communicate with one another. That’s great, as far as it goes, but it doesn’t go nearly far enough.
First, perhaps the most important task for anyone considering moving to microservices is how to partition functionality among them—in other words, how do you design the individual microservices?
Providing a basis for code components to talk to one another without assisting IT organizations with getting the right code in each service is the equivalent of converting one unwieldy monolith into a lot of little, individual monoliths.
Second, and more troubling, is the fact that this approach focuses on development while leaving out actually operating a microservices-architected application. The hallmarks of microservices environments are frequent releases, incremental service updates (i.e., deploying new functionality in a subset of services), and the monitoring of a constantly changing application topology with operational tools that support drill-down problem analysis. Providing a way to write and partition code without supporting the full application lifecycle for all involved groups only solves a small part of the problem.
Bottom line: If the framework doesn’t help every group involved in creating, running, managing, and updating a microservices application, it falls short of what it needs to deliver.
Lie #2: “We can convert your legacy applications to microservices”
With every new technology, vendors spring up that proclaim to have a magic lamp that, when rubbed, can take your old, clunky applications and convert them into the new, whiz-bang platform you’re hankering after. We saw this with client/server to Internet (browser-wrapping), virtualization (P2V), and cloud (in a kind of daily double, V2C). For all I know, there was probably a mainframe to mini (M2M) offering back in the day.
The reality of every one of these “solutions” is that they will solve easy things well and moderate problems poorly, while failing to even grapple with the most challenging situations. And guess what: The preponderance of legacy applications falls into that latter category. Even worse, many times the solution says it has done some conversion but instead has done it imperfectly, leaving difficult-to-track-down problems lurking in the updated application.
When it comes to microservices, the typical solution is encapsulating your ugly old application inside a container and claiming victory. Look, it’s a microservice! But it’s not, is it?
Shoving a monolithic code base into a container and calling it a service is like a python swallowing a pig—it’s inside all right, but nobody is going to say it’s sleek.
You still have all the problems you used to have, such as interdependent code, lengthy integration cycles, and no ability to let individual development groups release code on their own schedule. Plus it introduces some new ones, like how to get this new “service” talking to other, independently executing services.
There’s a name for converting a legacy application to a microservices one: refactoring. It involves assessing the different functional parts of an application, designing individual functions, programming service components, and integrating the delivery and operation of a collection of services into an aggregated application. It’s hard work, as you might imagine, and is only justified for important applications that justify the investment. Otherwise, it’s better to recognize that an application should be left undisturbed and untouched until it’s ready to be retired.
Bottom line: There’s no genie you can command to convert your legacy applications into microservices.
Lie #3: “All you need is our tool”
Every platform shift imposes change across all aspects of IT. Vendors and end users typically focus on the thing: the IDE, the security component, the data integration API, the … thing. And yet the primary barrier to platform adoption is always people: their education, their fear of change, their metrics and incentives, their relationships within the organizational structure.
At least part of the responsibility for this situation lies with the customer. Despite the fact that virtually every post-mortem of a failed project points most directly to people issues, IT organizations always believe that perfection lies in the next tool choice. This time, things will be different!
And vendors support IT organizations in this belief—because it leads to product sales. If a customer wants to believe that a tool will solve organizational issues, you can bet there will be a sales rep ready and willing to provide a rationale for the decision.
But guess what: Inevitably, adoption of this tool runs into the same roadblocks as the last one. And the one before that. And the one before that one.
Bringing new platforms into an organization is not an event. It’s a process. Failing to plan for all the activities and milestones that make up that process is asking for trouble. But failing to recognize this pattern and not placing the tool purchase inside a comprehensive organizational adoption process is also looking for trouble.
This is even more true with microservices, which must be accompanied by a DevOps capability. This is because most microservices benefits (e.g., small code base executables that facilitate frequent independent updates) require a DevOps foundation (e.g., continuous integration and deployment capability).
Without the DevOps process, you cannot attain the benefits of microservices.
DevOps cuts across organizational structure and commonly requires a change to roles and interactions, organizational metrics, and personal incentives. In other words, microservices adoption is a forcing function for organizational change, and no tool can bypass that effort.
So, recognize that the vendor has a reason to focus purely on a microservices tool purchase, but also recognize that if you want to get the most from your platform shift, you have to do the hard work of marrying the technology change to people change.
Bottom line: Never believe a vendor rep who says the vendor's tool can make the hard work of organizational change unnecessary.
Plenty of blame to go around
Hating software vendors is a time-honored IT tradition—one that is fully justified, in my opinion. Vendors have financial incentives to overpromise and underdeliver, and it’s completely comprehensible why their behavior aligns with those incentives. However, it’s critical to recognize that there is no innocent party in this affair. If IT organizations didn’t persist in their belief that somewhere there’s a magic product that somehow removes the work associated with migration to a new platform, there wouldn’t be any money in misrepresenting the capabilities of a product. So the next time you think you hear a vendor lying, think about who’s listening.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
