The state of services in the cloud for 2020

Services are really old school if you think about it. We’ve progressed from early efforts around API-enabling applications, to object-oriented programming, to CORBA-based services, to SOA, to containers, to serverless functions, to today’s use of microservices. 

What’s common about the journey is the underlying belief that we can write something once and use it many times in many different applications or utilities, not to mention the ability to combine services so they become a new service unto itself. This is done through service decomposition.

The word “service” is overused today; in the cloud computing world it describes anything that is exposed by a public cloud provider, such as storage, compute, database, etc. Services, at least the way I understand them, are the capability of exposing both behavior and data bound to that behavior in ways that allow developers to be more productive.

For example, a service might be built to do predictive analytics on any type of data set passed to it. Thus, it could be invoked from an inventory management application or a sales order entry system.

If the service is changed or improved, then both of those applications benefit. Also, by changing a single service, you change the way you do predictive analytics, without having to cull through the code of a hundred or so applications to fix or improve that feature. You place volatility into a domain, which is fundamental to good architecture.

Now the bad news. Lift and shift is the enemy of service orientation, as well as of cloud-native features. Moving applications to the cloud as fast as you can without regard for service enablement is a bad idea. Unfortunately, this is also the most popular way to migrate to the cloud, by far.

Copyright © 2020 IDG Communications, Inc.

Source link