Kloudless Blog

Kloudless Unified APIs enable you to code once and integrate many

Last week, we had the pleasure of attending GlueCon 2019 in Denver, Colorado, to proselytize the benefits of Kloudless and our Unified APIs. To read all about our experience at the tech conference, please head here to check out our detailed writeup of the event.

Besides having the opportunity to give our own speaking session, we had the good fortune of getting enough time in between booth duty to take in a few of the other guest speakers and their insightful offerings to the conference. One of them that I was fascinated by and wanted to take the time to dive into the topics covered was by Joyce Lin of Postman in her talk, “Escaping the Microservices Dependency Hell.”

Enter Postman

Image result for postman astronaut

For those that might live under a rock when it comes to API tools, Postman offers a wide range of services to help developers connect to and test APIs through their GUI-based development environment. They do this by making the process of API consumption and testing straightforward and undemanding.

Before Postman, developers constructed or wrote lengthy cURL requests or used HTTP-request libraries to test API responses. Now, through the use of the Postman client, developers can vastly cut down on the time needed to test APIs by storing necessary pieces of their requests such as environmental variables and authentication parameters, as well as a host of other helpful features.

As of today, Postman boasts over 7 million developers using their tools across 200,000 different companies. With over 13,000 publicly available APIs, it is no surprise that Postman has grown considerably since their first public release on the Chrome Web Store in 2012.

Remember if it Doesn’t Say Microservices, it’s Not the Real Thing!

Microservices is a bit of blanket term that refers more to a style of architecture than the actual implementation of specific code or feature-specific integrations. The best way to describe microservices would be as a software development technique or architecture of the overall code. Essentially, microservices is a collection of loosely coupled services for the sake of modularity. They are generally each small in size and developed autonomously in the aim of being independently deployable, decentralized, and released through automated processes.

Because of their modular nature, microservice bloat can lead to a handful of problems for codebases that don’t plan for the future when implementing this style of architecture. They rely heavily on messaging, and as a result, can run into problems with communication unless automated or developed in an Agile methodology. This can also result in more of a strain to the network, as latency and load balancing become more of a focal point in maintaining their communication. Microservices also require DevOps tools to manage their network, so advanced CI/CD servers are necessary for their deployment with application performance monitoring being paramount to their success in the long term.

While they both offer a handful of separate but interconnected services, microservices are not to be confused with a Unified API such as Kloudless offers. A Unified API abstracts away the differences between unique APIs and allows unified requests and responses to and from the server for data. Microservices are for equipping a codebase with all of the separate functionality it requires for its features, but are not a means of unifying the data or requests. Microservices provide a codebase with its own internal use cases, while a Unified API is to allow easier access and maintainability for external data.

Hell is Other Services

Check Conway's Law before speedboating into microservices please

Lin’s talk focused primarily on Postman’s use of Microservices and the headaches that their team ran into with managing the vertical slices of functionality. Their Workspaces feature used more than 20 microservices and, despite shipping in a record 3 months, led to a handful of issues for the development team as a result of their heavy microservices implementation. Firstly, their front end became bottlenecked due to the heavy use of separate back end services. Secondly, their database schemas were shared across services which led to bloat.

They found that because of their complicated implementation of microservices, simply understanding the back end architecture was a tall task for their engineers. New hires wouldn’t be able to step in and provide engineering work without first taking considerable time to fully digest the application flow, so a very limited group of their developers maintained and wrote about 80% of the code.

Their roadmap became deadlocked due to these constraints. Developer cycles became slower and the code quality suffered. They were in a state of what we refer to as “Dependency Hell.”

They were stuck with what is referred to as a Distributed Monolith — A predicament where services cannot interact within a system unless all shared libraries within are available. When splitting up microservices within a codebase, having them rely too heavily on each other means that although they are decoupled from one another, they still rely on each other in order to function properly. When logic is shared between these internal services, codebases lose the ability to deploy isolated pieces of functionality as they now affect all the internal services that share that same coded logic.

At the end of the day, microservices were providing Postman with great benefits that came accompanied by frustrating tradeoffs.

Enlisting in the Service to Fight Back

To combat these hardships, Postman worked from the top down on reorganizing their decision making processes and the structuring of their development teams. First, they came up with a (constantly evolving) microservice decision tree for reference. Next, they organized their development teams according to specifically avoiding the problems outlined by Conway’s law.

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

Melvin Conway
Image result for conway's law
C/O sketchplanations.com

This law is based on the notion that in order for a software module to properly function, multiple authors must communicate frequently with each other.  There is a counterpoint to Conway’s law, however,  known as the Inverse Conway Maneuver. This process involves reengineering the structure of an organization based on the desired software architecture. Ideally, the Inverse Conway Maneuver leads to business and technical teams becoming more closely aligned and, as a result, producing higher quality work.

To aid in this goal, they reorganized their developers into small, independent teams: Product Engineers, Service Engineers, and Platform Engineers. By splitting the development into these 3 specific roles, Postman was able to keep successfully divide their engineering responsibilities into coordinated teams that wouldn’t be forced to step on each other’s toes when it came to overlapping logic. They also were able to work and deploy features concurrently through the internal use of their own API testing tools. They used the same tools they offer publicly for blueprinting, negotiation, and finally development. To further help their goal of complete parallel development, Postman employed both contact testing and mock servers to test API features before the actual response data was in place, allowing their engineering teams to make over 11 million fake calls per month during development. Postman now needed to quantify the data of their success going forward, so they created a maturity model to evaluate and scorecard metrics to glean as much as possible for the future of the new organizational realignment.

Services With a Smile

Hearing about the struggles and subsequent successes of Postman’s experience in their Microservices implementation was a good reminder of a few things. First, incredibly competent and capable development teams still run into their own problems and are forced to take a step back and reevaluate their choices going forward. Second, it is never too late to fix something that isn’t working well. We’ve all stuck to our guns at points in the past and kept with a decision that might not be the best for our long term goals, but it takes a strong sense of dedication and awareness to reassess a situation and proceed in a different manner. In her session, Lin not only illustrated how this thought process benefitted her team at Postman but how any development team can learn from these lessons. In the end, it was bigger than simply the struggle of Microservices dependency, and more of a masterclass in reexamining decisions made in the past that can benefit from a second approach.

Kloudless has leveraged many of Postman’s tools in the past to help with our own API testing. Most recently, we build our own Postman Collection to give developers an even easier way to access our Unified APIs. To read all about our experience building the Kloudless Postman Collection, check out this article from our own Customer Success Engineer, Chris Prochnow.


Share this article:

Let’s get started. Start building for free today.