Microservices–The Enabler of APIs in DevOps

APIs should be in any DevOps discussion because they allow development teams to separate large applications into smaller, faster building ones. APIs also allow testing of a specific functionality just to the interface level to make sure your component behaves properly. In addition, APIs allow omni-channel (mobile, tablet, kiosks, etc.) microservices development to occur. APIs allow exposure to the functionality through all these channels. APIs are key because DevOps requires more frequent and hence faster build and test cycles. But microservices with APIs are even better. 

Consider APIs up front, so you can think about growth to multiple platforms. Prior to joining OpenLegacy, I supported a developer tool that needed an API to allow 3^rd party connections. We chose the COM API, Windows Only, because the tool supported only Windows. Over time the tool grew to support multiple interfaces for the same functionality. 

Having different interfaces led to increased development, testing, and maintenance. We tested against new releases of COM and Java. Eventually we deprecated the COM API, but it alienated some partners and customers.

APIs up front, so you think about growth to multiple platforms and don’t wind up with a problem like Windows specific APIs. If you don’t plan for an API up front, it winds up growing as needs arise and typically isn’t flexible enough to support different use cases. I am not saying to expose every piece of functionality immediately through the API, just to treat APIs as first-class citizens in the development effort.

Good APIs in and of themselves aren’t a guarantee that the underlying architecture doesn’t share the same components and data, which slows down build and test cycles  by requiring users to include many components to build and test just one. Microservices include APIs, data, and behaviors for the interaction between them in small, deployable components. So microservices, when implemented correctly, make it easier for development teams to simplify the build by containing the functionality with the interface.

Microservices make testing faster and easier because each unit is self-contained with interfaces to each other. You only need to test the ones that changed. Each microservice is a small, separately loadable entity so deployment is simpler. By contrast, traditional, monolithic applications build, test and deploy together so releases are less frequent and developers wait for the process to be completed.

I remember in a past role, our team wanted to support Continuous Integration, a component of DevOps (Continuous Delivery being the other part). Building our large application took a while. Most changes required a complete build and to re-run our whole test suite. We sped it up a little with smart building and modifying our test suites, but we still had long build and test cycles. Our build and test cycle inhibited our move to Continuous Integration, never mind the move to complete DevOps. Microservices and their APIs help this development effort by splitting the product and allowing building and testing of individual components. We felt the effort to build everything as microservices was too large. This is where OpenLegacy helps, because it automatically generates microservices from your current legacy or on-prem systems.

Please join our webinar on February 12^th featuring Craig Beattie with industry analyst firm Celent and OpenLegacy’s Chief Product Officer Zeev Avidan to learn more about how to leverage microservices in legacy systems.