Introduction

2019 has been full of buzz words: microservices, devOps, agile, cloud ready, cloud native, cloud first, etc... It can get really confusing to follow all those trends. I must say though, I'm glad to see the industry moving forward and trying to push the limits and practices further. Developers are no longer perceived as weird guys in their garage, but more and more as professionals on top of their craft, running serious businesses. Software has never been as important as it is right now for businesses. As Satya Nadella (Microsoft CEO) like to say:

Every company is a software company.

State of the industry

If you look a bit around, you'll see that all the DevOps success stories are always about those super big companies like Uber, Netflix and Facebook. They have crazy automation in place and run at a scale that you and I will probably never achieve. Don't get me wrong, I think it's great that the industry's leaders share their stories. And although I don't run 100s of microservices in 1000s of containers, I would like to achieve something similar and get to that level of quality and automation. So where do I start? How do I apply those concepts? What's the road to get there at a smaller scale.

In this blog series, I'll talk about our DevOps story, how we implemented it and why we made the decisions we made. I'll go through what worked and what didn't. (And yes we made a lot of mistakes along the way).

Disclaimer

I don't claim to have the magic formula for everything. What worked for us, might not work for you. So please, don't just follow what you'll read and apply it blindly.

Our context

It all started over a year ago. Our current application was struggling to scale, and making new innovations was long and painful. That's when we decided to port it to a new technology stack and embrace a DevOps mindset. It's also important to mention that we have a special context: we are providing SaaS products in the Pharmaceutical industry, which means a LOT of red tape. It can be a pain in the ass sometimes, but on the bright side it should make this blog series pretty interesting.

Microservices

Yeah yeah I know, you are fed up with all those microservices talks. Unfortunately, it's still one of the major changes that happened in our industry over the last decade. It's also the foundation of everything else in our DevOps story, so pardon me, but I'll have to go over it.

One of the first decision our team made was to move towards a microservice architecture. Based on our current pains, we used the following decision drivers:

Different parts of the application must be able to scale independently
Teams must have full ownership over part(s) of the application
Teams must be fully autonomous in every part of the Software Development Life Cycle (SDLC)
A failure will degrade the user experience, but should never take down the whole platform

Implementation details

Concretely, we chose Service Fabric as our microservice platform. Mainly, because we are a .net shop, so it just made sense for us to stay on the Microsoft's stack and leverage our current knowledge. Moreover, Service Fabric has interesting attributes.

Maturity

Service Fabric is a battle tested platform that runs some of the biggest workloads on the web. Microsoft has been using it for many years, powering their biggest applications like Bing, Azure and Xbox, to name a few.

Operability

Service Fabric offers a nice explorer where you can monitor all your nodes, applications, services, replicas and partitions. From there, you can also perform deployments, rolling upgrades and so on. Scaling is as easy as moving a slider to the right and if you want to, you can even automate it.

Flexibility

One really important thing when making big architecture decisions like this one is to make sure that we are not trapping ourselves in a corner with a technology that might be obsolete in a few years. That's one of the aspects I love the most about Service Fabric. It supports not only .net workloads, but standalone .exe applications and containers. With all of that supported, it's almost impossible to be out of options in the future.

Extra

On top of all of this, what makes Service Fabric a great platform is that it does way more than just orchestrating your workloads over a cluster of virtual machines. It provides, out of the box, its own constructs to enable a seamless experience developing microservices. Namely, it offers Stateless and Stateful services, automatic backup, reverse proxy and a complete actor framework. It's also good to point out that Microsoft has created an exceptional documentation for Service Fabric. Not only they cover the whole platform, but they also provide best practices for developing microservices, and they have sample applications on github for many different uses cases.

Closing word

Now that we have presented the foundation of our system, stay tuned for the next posts to learn exactly how we leverage it in every aspect of our DevOps practice.

I hope you liked the format. If you have any questions or feedback, please let me know in the comments. I'll be glad to cover any topic in more details.

Also in this series

Microservices (this post)
Bounded-Context
...

Subscribe to Miguel Bernard's blog