Hi Melanie,
Full disclaimer: I am a consultant CTO for a relatively small Fintech startup where everyone works fully remotely across different timezones, but I have worked in (much) larger organisations.
Microservices are the (current) pinnacle of agile software engineering. They are supposed to be small, focused on doing one thing and one thing only, but doing it extremely well.
In my opinion, to be able to deliver microservices efficiently, you need to make your organisation and operations as agile as the service itself. I don't see how a waterfall project management style, with large teams of developers, could be efficient in that scenario. I have found that the opposite was pretty much required.
Project Management Style:
Something Agile based, but done the right way. I have seen too many times teams saying that they are following an agile process and yet the senior management or marketing department are imposing deadlines without negotiation of features, or requesting Gantt Charts before starting the project. Agile is not time based, it's feature based.
I have experimented and found these two approaches to be equally viable:
An Agile Scrum style of project management, with real story pointing and a real buy-in from the senior management. The Product Owner and stakeholders defining the
what, the development team investigating and deciding the
how leaving the
when to be the most flexible data point. Sprint lengths of 2 weeks to a month maximum. If that's not long enough to produce the microservice (in its MVP version), the microservice is probably too big and should be split.
A Kanban approach, again focusing on the
what and the
how, with the
when being set by the priority in the backlog. The Kanban approach makes it a bit harder to draw a line on when a microservice is "too big", but is as effective and allows more flexibility for the changes coming from the business.
Team Organisation:
One thing that I have found, is that the larger the teams, the least efficient they become.
3 to 4 developers per "strike team" is the sweet spot in my opinion. With one or 2 seniors per team. More than that and the team efficiency drops, you need more meetings to keep everyone in the loop, and you have more "opinionated discussions" about how to implement a feature.
It's also down to the fact that there is only a maximum number of people working on the same bit of code (or even the same branch) before it becomes an organisational nightmare and "merges of doom" with conflicts everywhere.
Code Organisation:Beyond having code repositories like Git (yay!) or SVN (boo!) and having a set of common libraries: A template for the "base service" to integrate with the existing (microservice) architecture. That could be a set of templates, because the beauty of microservices is that you can really chose the best tools or languages for the task.
Want something very lean, very fast, secure, for the web? Do it in Golang.
Want something with a bit more features or support (or even broader knowledge), go with Java Spring Boot.
AI, Machine Learning, Deep Learning? An H2O cluster, Python, or the tensorflow library will work a charm.
Worried about the pushes to production? Bamboo or Jenkins can pack your code nicely into whatever is convenient for you (or a docker file) and publish it accordingly. CI/CD is a breeze
Code coverage: Since the services are meant to be small, they are much easier to test. 95% coverage is my minimum acceptable, split between unit, integration and acceptance tests. If it has some front ent features, throw in a bit of Selenium for good measure and you are all set.
Conclusion:
Starting from greenfield projects, in a startup, what I am describing is very easy to implement. In a larger structure, it is not impossible, it needs buy in from the senior management, the stakeholders and the developers. But once it is in place (and there are growing pains, there isn't a magic cookie cutter), the time to market for each new feature will be much faster than what you could have experienced in the past.
Because the microservices themselves are so small, and using so few resources to produce, they are also ok to fail and learn from. It's easier to iterate over a feature implementation, using different approaches, than build a semi-monolith that doesn't really work and try and patch it as much as possible, often throwing more developers at it. Instead, look at your MVP, if there are issues that are not easy fixes, tear it apart and try again in a new language, different framework, or variation of features. It's not free, but it's much cheaper than the alternative.
The main challenge is the change management and the period of transition. After that you will be living in a world of much less bugs, and much faster software delivery.
If you have any specific questions or want more details feel free to reach out.
------------------------------
Julien Frisquet
Chief Technical Officer
------------------------------
Original Message:
Sent: 03-14-2017 08:51
From: Melanie DiGeorge
Subject: Microservices and why you should care
I know there is a great discussion around microservices right here in the API community and after reading this article, I wanted to get your opinion and continue the discussion.
Microservices is a huge shift in how companies build, deliver, and use software. Large applications are broken down into small, loosely coupled, compassable pieces that are autonomous.
Google, Amazon, and Facebook have been running microservices for over a decade. But, the right building blocks for mass adoption are now in place. Still, to start reaping the benefits of a mircroservices architecture it requires a true business transformation, encompassing IT, processes, people and culture.
I’m interested to hear, what do you see as the operational and organizational challenges of microservices?
------------------------------
Melanie DiGeorge
Community Manager
TM Forum
------------------------------