Deployment Woes

Often where to deploy the given microservice? is a critical question to answer, especially when you are into the architect’s shoes. Deployment matters due to below factors:

  1. Access required by the microservice to other resources
  2. Other resources requiring access to this microservice
  3. Data management – ability to migrate, update, add and delete data used by micro service. Aspects like, who and how should one have access to carry out these tasks? How frequently the data needs to be managed? are answered
  4. Security – Protecting the resources using tough authentication mechanisms, implementation of firewall settings, usage of client certificates, multiple factor authentication etc.
  5. CI/CD – alignment of new microservice with existing DevOps pipeline.

In a greenfield implementation, it is not challenging at all because you are the one defining the rules. But, planning an additional micro-service into an already existing landscape can get to you if above concerns are not addressed. It gets specifically difficult when there is no defined process, or nobody has thought about onboarding a new microservice in the future in a systematic way. I doubt if it even makes sense to do it, because the degree of standardization while developing a product is reduced. I mean, if anything can be standardized why bother making a product out of it? Products are here to make lives easier by taking care of such aspects.

As an architect you have to first know the existing situation with deployment, carefully think of options which address all the constraints, define the network access requirement, create a plan to containerise and align with existing CI/CD etc. For a while it feels like a constant battle of requirements and constraints – till the time you come up with a few good approaches. You then present these approaches in an architecture board where it is heavily brainstormed. Having merciless brainstorming sessions are very helpful, because this builds the strength of the product.

You really need to be a strong architect if you have to defend your solution and arrive at a conclusion – and that’s just a part of the job.


Tagged as: , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s