Microservices - serve the customer and protect the business
Here are few of my personal observations & opinions as a Microservices practitioner…
“Microservices are autonomous services that work together, modeled around a business domain, decentralized, and hides implementation detail” *
As a microservice designer, our task is to create a bare minimum Domain model and that starts with listening to the subject matter experts. These are the folks who are either in charge of existing APIs or understand what needs to be built and monetized. If the customer is coming from a monolith world, chances are they will hand us a WSDL, Swagger or something. This is where we will not be afraid to assume the new microservices consumer has nothing to do with these old SOAP or REST endpoints. I would recommend to have a serving the customer mindset. This is Greenfield development with fresh new set of versioning strategy, service discovery, health checks, API docs and other tools that not only support the UI developers but also the API channel partner integrators. Lookup “Full Life Cycle API Management” for more details on this topic.
“Implementation of Microservices should have a culture of automation, independent deployments, with resilience and failure isolation, and with monitoring and observables” *
As a microservice implementor, our task is to either create or work on a Deployment model with understanding of SDLC, change Management, and overall IT infrastructure. Although this sounds like Cloud and DevOps in general, there are few culture and sticker price shocks to overcome in order to offer a customer experience of new and shiny (read expensive) API Gateway. I would recommend to have a protecting the line of business mindset. This is a series of brand new set of tools and processes like source code management, testing automation, instrumentation, security, hardening, and scalability. Analyzing, quantifying, and mitigating risks can be the key to sustainable business growth, solution flexibility, and speed to market. Lookup “FMEA (Failure mode effects analysis)” for more details on this topic.
Finally, as a microservice developer, whether monoliths are being migrated or new capabilities are getting created, the practical standards, guidelines, templates, conventions, and an overall Component model has to be agreed upon and put in place. Shared and Common components like identity services & providers, user management, logging & error handling, monitoring & analytics, private key & connection string storage etc. need to be built first. It is ok to reference these components not only from the different microservices projects but also the UI ones as we move from the SPA monoliths to micro-frontends.
*Reference: https://samnewman.io/talks/principles-of-microservices
