Skip to main content

Microservice Architecture, but NOT microservice mindset?

Microservice Architecture, but NOT microservice mindset?
We are on the same team!
Let's say we as a company decide to implement the microservice architecture and we also decide to split the teams into domains for each team to own a domain (group of microservices). You may be a member of team A and I may be a member of team B and we are all on the same ship. There is a water leak in your area of the ship, but my side of the ship looks good.  What do we do? Let's help out each other because we are all members/passengers on the same ship. We are all going to the same destination :) Microservice teams were created to pave domain boundaries at the architectural level, but it does not mean that we should create boundaries among members of different domain team members. Yes, the API contracts are definitions for how our services communicate, but for the sake of final destination, we need to tear down those boundaries when it comes to approaching each other for help and proactive integration. It is beautiful to see ONE team in action especially in crunch time.


Almir Mustafic


Labels:

Comments

Post a Comment

Popular posts from this blog

Brand New programming language and one solution OR …

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...
Post a Comment
Read more

AMAZON WORKSPACES

AMAZON WORKSPACES. I am not sure how many of you have heard of Amazon WorkSpaces. Let me give you some information and my analysis after using it for some time. What is it? It is the Amazon’s solution to desktops in the cloud. What’s the point? Well, if you want to use a basic less powerful laptop or even use a Chromebook as your daily computer, then you will not be missing the full functionality of a powerful Windows 10 machine. For example, you can use your Chromebook to connect to your Amazon WorkSpace machine and then you get the full Windows 10 experience. The point is that it gives you the experience as if your remote/workspace Windows 10 machine is really part of your Chromebook. Where it makes the most sense is using Chromebooks to connect to your Amazon WorkSpace machine as Chromebooks with Chrome OS are fast for anything you do in the browser and they are very secure; Chromebooks are also generally cheaper than other laptops. Just a thought as an alternative to buying ful...
Post a Comment
Read more

POCs ??

Imagine the world of software architecture where every POC becomes a production software without changes. That’s one extreme. Now imagine the opposite where no POCs get done and no free innovation happens and everything has to be 110% planned and build perfect from day one. If you and your team can take the good aspects of both extremes and combine into one nice approach, then you will innovate and that innovation will turn into enterprise worthy software. Thank you for reading. Almir Mustafic
Post a Comment
Read more