In the tech world one cannot stay a day away from hearing the words API or Microservices. For those who work in startups or tech firms (google type) these are well understood. But once you walk into large non-tech firms, these words are not as well understood.

It is not that the folks working in non-tech firms are not smart; but it is because these firms are built to avoid business risk at any cost, which therefore means tech innovation is not a priority. Decades of building moats and walls to protect around every possible risk means there is no place for the techies working here to run for attention. Traditionally non-tech firms are those that maybe into finance, healthcare, government, etc. Many of these industries have a ton of government regulations that they need to abide by. Sarbanes Oxley, SoD (separation of duties), privacy controls, governance, etc. are what these firms have their internal foundations built on. Finally startups have the advantage of starting greenfield; most firms that have been around for a few years do not have that luxury. Legacy systems are all over the map and run critical business functions. Moving to an API based Microservices architecture is a tectonic shift for such firms.

An API is the smallest, most pragmatic and usable service that you can expose to your consumers (be it internal or external). API’s are most often built using a RESTful Architecture style and over HTTP which is ubiquitous. No more heavyweight XML SOAP based web services. No more worrying about SOAP interoperability. If you can speak HTTP then you are good to go in this new world. Every mobile device can speak HTTP and that in itself is a win for HTTP. An API by itself does not dictate a deployment model. You can deploy one artifact that has a 100 API endpoints or you can deploy one artifact per API. Most firms are better skilled at the earlier model since their organizational structure has been built to support that.

Conway’s law states – “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

Read that carefully and if you work in a large firm; see if it fits. For example in many large firms the developer writes the code, produces tons of documentation that no one reads except mandated by the process, if lucky the developer can put in a ticket to deploy to dev environment, but if database changes are needed then you need a data modelers to align to data modeling standards, then tell the database administrator via a ticket to deploy the changes and then coordinate the deployment of code, if things go south then all hell breaks loose in trying to turn back, there is some CI running so someone can check a box, enterprise governance of all kinds. All this is to just deploy to the dev environment. Now if you need to deploy to system test, UAT (forget prod for now) then you have to get approvals from the test organization (maybe UAT organization if you have one), put in many more tickets and then wait for the dedicated build team, who does not work with you, to build the code and of course don’t forget they need to coordinate with database team too. If build breaks then these silo’ed build team will have no clue what to do and the whole cycle starts again beginning with the developer resolving the issue first. The prod environment is even worse. Take all that I wrote and add more governance. If you need hardware or virtual machines then there will be more tickets and potentially many days/weeks of waiting. Often you have to design infrastructure needs for the anticipated peak volumes. I stop right there before I run out of breath. But you get the point.

Martin Fowler has a great description of Microservices  – “the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

You can have an API architecture style without necessarily embracing a full fledged Microservices style. Start with an API architecture and over time you will find yourself embracing best practices and design strategies from the Mircoservices realm.

An API or Microservices architecture culture brings with it things that are completely the opposite of this business as usual model. I emphasize the word culture since this is truly a cultural shift for an organization. Yes there are technical challenges with running a Microservices architecture but the cultural ones will be more challenging in my opinion. I note a few random things that organizations will need to embrace…(my opinion only)…

• A robust Continuous Integration (CI) capability. One that runs at scale and can execute the build process for all components of the platform.
• A Continuous Deployment (CD) model that will take new code, run it through another pipeline which runs unit tests, integration tests, makes automatic db changes and then deploys the code.
• A DevOps culture where ops team is part of the dev team and the dev team is part of the ops team. There is no other ops team other than this ops teams. I have seen situations where the so-called “devops” team only exist to fill in tickets and protect the developers from having to do that. Thanks but no thanks.
• A culture that embraces failure. If you do not fail then you have failed. The only way to learn is to fall first, fail often and pick up with lessons learned. This part is especially hard for large firms; thus making folks to take safe bets all the time or simply passing the buck on making hard decisions.
• Embrace the NIST definition of Cloud (be it internal private or public cloud). “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”
• Stop the urge to build large teams. Its easier to find 10 good people vs. trying to staff 100 people. The ability to attract the 10 smartest developers to your organization is a key aspect to focus on since it is relatively easy to find the 100 mediocre developers. When you staff large teams with a date in mind, quality takes a backseat.
• Focus on just enough capacity planning and don’t fret over designing for the peak. Let the elasticity in your IaaS or PaaS architecture take that responsibility.
• Oh and Cloud elasticity is not an excuse to build crappy code.
• You should be able to at least move your code (via CI/CD) from dev to test to UAT throughout the agile sprint cycle. I leave production out for now since that maybe harder to achieve during initial round of this exercise.
• Have a sense of what a “micro” means for your organization but let teams make the decisions.
• Gathering real time operational metrics on your API & infrastructure must be a top priority.
• Design for failure. In a API/Service based architecture you will eventually have 100s of services invoking each other. Latency suddenly becomes a big issue. Designing on how to handle latency and more importantly making sure your code can react and heal must be part of your design.
• Ok so you use RESTful API style but don’t forget to publish some form of API description. Use DSL’s like RAML or Swagger but use one. Some of these DSL’s will also allow you to generate working stubs so consumer code can begin integrating as you go about actually writing the implementation.
• A great place to reflect on how to design for such architectures is “The 12-factor App” design strategies. Certain ones such as sending configuration values via environment variables must be (IMO) taken for its spirit, which in this case is to keep environment specific variables outside of the code. If environment variables work for you then go ahead.
• In such highly distributed architectures it is important to treat logs as data. Aggregate them, use the aggregated data for production issue analysis or do some type of intelligent pattern recognition as the case maybe.
• etc. etc. etc.

One of the great advantages of an API based or Microservices architecture is that your services can now have an independent life of their own. In a monolithic architecture style, all parts of your application need to be scaled together and technology decisions once made are pretty much done. Once written in say Java you cannot just move the application to nodejs if you so choose. You can apply what Martin Fowler calls the “strangler” and eventually retire the legacy if you so choose. One other key benefit is that you now have the flexibility to organize your teams around API’s or products vs. traditional projects. Time to market for individual API’s are a lot faster than for big large projects. For enterprises the shift in modifying (or in some cases eliminating) data governance, security governance and traditional SOA governance will require a senior leadership CIO/CTO push to make happen. Silo’s once built have a tendency to stay intact in some form or the other.

The benefits are great but operational complexities are big too. Once the culture shifts and technology architecture foundations are implemented; only then can one begin recognizing the measurable benefits.