4 ms·

Microservices requires proper, structured systems management. Most seem to think "devops" and microservices are ways to ignore this, when in fact the complete o

Microservices requires proper, structured systems management. Most seem to think "devops" and microservices are ways to ignore this, when in fact the complete opposite applies. Make sure you have a true service delivery and service management pipeline in place where it is real easy for dev and ops to deploy and decommission services. Service metadata is key in my experience. Not too much though, just enough (such as service owner, deployment scopes, a release database, etc...). Nothing gets deployed without this metadata present, and make sure to automate the creation and keeping of these records. Make sure convention before configuration applies, in most cases this is doable. This stuff, in my experience, takes somewhere 6-12 months to put into place, including the actual automations/orchestration (be it the hashicorp stack, kubernetes, dc/os, triton, whatever). Do not even think about starting to move to prod before everyone have agreed upon the conventions and operational situation surrounding the stack and services. Other than this, it's just code and integrations. Business logic. =) In my last project we moved from 0 to 200 fully managed microservices using the hashicorp stack (plus a bunch of other stuff and homegrown things as well such as service metadata and release database/apis) and the biggest challenge was having everyone agree on the conventions. Convincing the developers that this type of house-keeping will be necessary, perhaps not today, or next month, but down the line took a few months. In the end it was a massive success that really accelerated the way we could deliver value to the business. When it comes to the data and ETL part you get a lot for free if the above is done decently. From my perspective the data scientists and ML guys need this stuff as well to be able to deploy and modify ETL flows and data pipelines at will. They'll most likely want to deploy some python, R and/or shiny apps as well! =) They (can) benefit greatly from getting integrated in the same automations Selling points achieved in above mentioned "transformation"/project: - 14.000 production deployments with 45 devs and 3 "ops" guys (dev, ops, devops?)" in about a year. ("But why!?" someone will ask! And I'll be happy to respond.) - Things started to happen, such as "could we just not provide this [insert awesome thing] to end users?" And what would have taken 6 months before could be pushed to canary days or even hours later. - One specific feature I can think about increased revenue with more than a million dollars per month, and it took one of the teams exactly two days to build and release. Granted, this was within a multibillion turnaround enterprise. Most businesses would benefit from this transformation, but it requires a blend of people and technology that probably is difficult to attain outside the proper "tech" industry. And my experience from within "small" tech is that focus sometimes is, understandably so, not situated around what I call systems management and service delivery. Phew, that went on... sorry! =)

9dev 8y ago
But why!?
- jordanbeiber 8y ago
  Good question! :) My thoughts and experiences: Because once you are up to speed the business and devs work more in concert, which lets things flow fast, especially if changes are small and many, rather than fewer and larger. As devs grow secure in the infrastructure (”it kinda just works” from their end) as well as the ability to roll back within seconds, deploying things to production becomes no big deal. The ”separation of concerns” and containerization enable some of this, but only part is tech — I find a great deal is rooted in the culture and people of the same mindset working together.
mooreds 8y ago
> Granted, this was within a multibillion turnaround enterprise. > Most businesses would benefit from this transformation... That is a great story from the front lines. Thank you for sharing. My worry is when I see small companies or startups using microservices. That seems nutty to me
- jordanbeiber 8y ago
  The money bit was more about rolling a change that means instant revenue increase in the millions, rather than people or product scale, but I agree that you need to put some serious effort into service management that might not make sense for a really small team. Not sure where there’s a natural threshold other than when you realize you can’t deliver on business needs and requirements rapidly enough. This is probably not in the beginning with a small team.

9dev 8y ago

But why!?

jordanbeiber 8y ago
Good question! :) My thoughts and experiences: Because once you are up to speed the business and devs work more in concert, which lets things flow fast, especially if changes are small and many, rather than fewer and larger. As devs grow secure in the infrastructure (”it kinda just works” from their end) as well as the ability to roll back within seconds, deploying things to production becomes no big deal. The ”separation of concerns” and containerization enable some of this, but only part is tech — I find a great deal is rooted in the culture and people of the same mindset working together.

mooreds 8y ago

> Granted, this was within a multibillion turnaround enterprise. > Most businesses would benefit from this transformation... That is a great story from the front lines. Thank you for sharing. My worry is when I see small companies or startups using microservices. That seems nutty to me

jordanbeiber 8y ago
The money bit was more about rolling a change that means instant revenue increase in the millions, rather than people or product scale, but I agree that you need to put some serious effort into service management that might not make sense for a really small team. Not sure where there’s a natural threshold other than when you realize you can’t deliver on business needs and requirements rapidly enough. This is probably not in the beginning with a small team.