Software Engineering Asked by stevanity on February 28, 2021
In our organization we’re looking to adopt a service oriented architecture where new requirements (that are natural bounded contexts) are being built as separate services that integrate into the main monolith as APIs & sometimes frontends as well (iframes today, we’ll use some form of webcomponents later on).
Today our monolith dev pipeline has few fixed non-prod environments (qa, staging, demo, etc). As we build separate services, is the best practice to have these services be part of these non-prod environments?
The other option I see is that we could just staging
& production
for these smaller services and point all non-prod monolith environments to the staging
environment. But then the issue becomes the single staging
environment needs to be built to isolate & handle data from different monolith environments.
I understand that the cleanest and safest approach is to have all services (including the monolith) to be running together in any & all environments. But then coordinating between the folks responsible for these services also becomes necessary right?
Also, we’re looking to provide developers their own on-demand preview environments. In such cases as well, do we have to have all these other services spun up?
Before we take a short-cut approach to this problem, I just wanted to get an idea of unforeseen consequences that others might have faced in their teams.
While things are hybrid
If your monolith is difficult to deploy, requires a lot of resources, or has licensing costs even for development environments; then you'll need to limit the number of instances where the monolith lives. Your option is to create a simulator to manually do things the monolith would do so you can test the microservices, or directly manipulate data stores using your tests.
However, if your monolith is pretty easy to deploy, you can automate it's deployment as well. It would be a "bigger" service, so to speak.
Ideal Environment
You'll find that one of the key factors of success in microservices is automating the deployment as much as possible. Whether you use Chef, Salt, TerraForm, CloudFormation, containerize with an orchestration layer like Kubernetes is a choice you'll have to decide on.
There are many ways of solving this problem, but the heart of it is that you need to make your deployment and configuration as automated as possible. Some of the ways to make that easier include:
By having deployment as part of the whole process, your question answers itself. Once you've gone through the hassle of automating the deployment and configuring the different environments appropriately, why wouldn't you just deploy your service when changes are made in all environments? That makes automated and ad hoc testing easier to do.
Team Responsibilities
When you talk to large software teams like Amazon (the store front), NetFlix, AirBnB, etc. there is a common mantra. I.e. there should be one team per service. That team is responsible for everything related to the service, including deployment, testing, recovery testing, monitoring, etc. The teams would ideally be a 2 pizza team (roughly 5-8 people depending on how hungry they are).
For smaller development teams like mine, that's just not something that most companies have the luxury of doing. For example, I have two teams working for me, integrating and building out two applications into one. To handle coordination efforts, we do incorporate planning meetings with our normal scrum cadence.
Our releases are typically 4 sprints worth of work, and then deployment to production. However, our customer has a lot more bureaucracy to release software than if we were a commercial group. Your experience may likely be different. However, I can say from experience, the more often you deploy the more critical automating that deployment is.
Correct answer by Berin Loritsch on February 28, 2021
I wrote down a 6 minutes blog-post dedicated specifically to this subject. I'll break it down to a few points here (essentially, it's a TL;DR) and add a few points related to the author's question.
There are many more reasons why you should separate your environments, but I think that's enough for now. I hope it helped.
Answered by Meir Gabay on February 28, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP