DevEx and DevOps

Designing effective onboarding to scale to 1000’s of Engineers from 60+ countries

Feature Toggle is one of the key practices for Continuous Delivery, but not enough has spoken about the same. Feature branching is popular, but everyone knows about the “merge hell”, a common issue because of long-lived branches or infrequent integration. How do you continuously merge, test and release software with great confidence without spending too much time on merging and fixing conflict issues? That is where Mainline development, one of the key practices of Continuous Delivery, comes into the picture and Feature Toggle works in conjunction with the same. Feature Toggle [also referred to as Feature Flip, Feature Switch, Feature flag] is a simple technique which allows you to turn on or off a feature through configuration. Feature toggles give you the flexibility to toggle features in specific environments i.e. turn on a feature in testing or staging servers and turn it off the same in production. This also helps to rollback features, as rolling back is as simple as turning off the feature and deploying.

Many times, it’s just not worth it!

I have been championing MicroServices for well over a decade. But I don’t always go to a MicroService solution for my clients’ problems. In this talk, I will characterize the traits that should drive you to avoid MicroServices, and instead look toward more traditional or even SOA alternatives. Included in the talk is my recent experiences in two Norwegian government projects, both very successful, with minimal MicroService influences.

“If you aren’t doing MicroServices, you are building an obsolete system!”

“MicroServices are the way to go if I want to keep my job.”

“If it is good enough for Netflix, it should be good enough for us.”

I hear all of these things as I attend conferences. And I feel apprehension for these companies, suspecting that the vast majority will fail. And failure will come from several sources:
* Little or no experience with MicroServices.
* Processes from traditional systems being forced on MicroService projects.
* MicroServices is not the appropriate architecture for the problem!

In this talk, I will focus on the latter issue. The other two issues will resolve themselves with time and experience. The latter issue will always be fatal!

First, we will discuss the problem domains particularly appropriate for MicroServices. Then we will address the radical differences in processes, team organization, and business management of MicroService and non-MicroService approaches.

Finally, we will touch on two recent projects for the Norwegian government, their overall architecture, and their minimal use of MicroServices. We will note, however, that they do exploit event buses, continuous deployments, and modern languages. So despite not being MicroService-based, they are being successfully deployed.