Overdoing service-focused cloud development

Service-oriented development is older than most people realize. Yes, the notion of microservices is a relatively new trend; however, developers have used services for years to build applications and orchestrations out of existing services that you don’t develop or net-new services that you do develop.

It doesn’t matter if you call a service a microservice, a fine-grained service, a utility service (such as cloud storage APIs or services), or a common application API to access behavior and/or data. Leveraging services typically means that you use a service-oriented architecture that focuses on building applications out of new or preexisting components.

Technology used to limit how many services you could use within a single application and what those services did. Back in the day, using too many fine-grained services (services that did discrete things such as update a database with a specific type of data) caused performance problems if they were used too many times within the same application.

These days we can hide performance issues by tossing cheap compute, networking, and storage systems at the problem. The inefficiency is still there, but it’s been abstracted by new generations of enhanced application processing that push out performance problems. The use of services is no longer a matter of if you can. Instead, it becomes a question of how much should you use services? Should you even use them in the first place?

The overuse of services I see now typically involves microservices, to a point where the application becomes overly complex, leveraging so many services that it’s impossible to decipher the core developer’s original intent. What also happens too frequently is the breakout of a single aspect of the application to services, even though the service will only be used once during processing and never by other applications.

This is one of those situations where the final deployed application works, and it even solves the core business requirements assigned to the project. However, the application’s overuse of services of all types makes it more complex, which could cause performance issues, considering the number of times it reaches out to external services that typically run elsewhere. Excessive use of services also means the application takes twice as long to build, test, and deploy.

Before the haters call me out on the proper use of services, I’m generalizing here. To use or not use services will never be a binary answer. I promote using services as the best approach to build more dynamic and agile applications, typically with faster development cycles and better quality. However, I also see developers drive off a cliff by overusing services. Again, the too-frequent outcome is too much complexity, performance problems, and even unstable applications as they operate long term.

So, what are the rules of thumb to avoid the downsides of services?

First, watch out for services that you call only once—services that will never be called by other applications. It’s best not to turn those into services, generally speaking.

Second, build with an optimization mindset. Look at the number of resources being used as the application runs on a public cloud. Remember, each use of a cloud resource turns into higher cloud bills. Without an optimization metric in mind, applications can easily overuse services and raise charges for networking, compute, and other services. The development platform, operating systems, and use of cloud-native services must all come into play when you consider application resource optimization.

Finally, use your head. These are basic, general rules; you’ll be the ultimate guide to how they apply to your specific platform. Most developers realize that when they overuse services, the application will be worse off. My core message is that when it comes to service-focused cloud development, it’s easy to take a good thing too far.