The use of feature flags has evolved and expanded as teams now recognize the value they can bring to their releases. 

First, let’s start with a simple definition of feature flags. A feature flag is a software development technique that lets you turn functionalities on and off to test new features in production without changing code.

This means that feature flags significantly accelerate software development processes while giving teams greater control and autonomy over releases.

Keep reading: Our complete guide to feature flagging

This is a technique that can be employed by all teams in an organization across a wide range of use cases, from the most simple to more advanced uses to improve their daily workflows. 

In this article, we will explore these different uses to illustrate what feature flags can do across different contexts depending on your pain points and objectives.

Feature flags examples and use cases

Many of the use cases outlined below allow teams to take back control of releases and enable them to deliver new features quickly and safely. There may be a bug in production and you want to turn it off without delaying the release or you have second thoughts about a feature and you’re not ready for all your users to see it so you’d rather test this feature on a subset of users. 

Feature flags also increase productivity and speed of teams. You’re no longer waiting to merge your code if other changes are incomplete; you just put it behind a flag until it’s ready. With this, you get more predictability to your releases. There’s no need to delay your release cycle for any last-minute bugs detected. 

Therefore, we will see how the use cases outlined below bring these benefits to your team.

• Prepare for launch
• Hassle-free deployments: Release anytime by decoupling release from deployment
• Experience rollouts and progressive delivery
• Time your launch
• Running experiments and A/B testing
• Continuous integration and continuous delivery
• Managing access: User targeting
• Risk mitigation
• Test in production
• Feature flags and mobile app deployment: Bypass app store validation
• Kill Switch: Feature rollback
• Sunsetting features
• Managing migrations
• Feature flags as circuit breakers
• Bottomline: Use feature flags often but proceed with caution

Prepare for launch

Hassle-free deployments: Release anytime by decoupling release from deployment

Feature flags allow you to deploy whenever you and your team sees fit. You no longer need to delay your releases. Any changes to a feature that are not yet ready can be toggled off with a switch.

What feature flags do in this scenario is separate code deployment from release. This is done through a release toggle, which allows specific parts of a feature to be activated or deactivated so any unfinished features will remain invisible to users until they are ready to be released. 

Why is the distinction between deployment and release significant? To answer this question, it is worth noting the difference between the two terms:

• Deployment is the process of putting code in its final destination on a server or any other place in your infrastructure where your code will run.
• Release is exposing your code to your end-users and so it is the moment when they get access to your new features.

This difference is why we talk about decoupling deployment from release because once you do that, you can push code anywhere, anytime, without impacting your users. Then, you can release gradually and selectively whenever you’re ready through progressive and controlled rollouts as we will see below.

Experience rollouts and progressive delivery

With feature flags, you are in complete control. This means once you have a feature ready for release, you can control which subset of users will see this feature through phased rollout of releases. 

When we talk about experience rollouts, we’re referring to the risk-free deployment of  features that improve and optimize the customer experience.

This is usually achieved through progressive rollouts, which builds on continuous delivery to include the use of feature flags to gradually introduce features to your users.

Rather than releasing to all your users, which is often risky, you may want to release to just 5% or 10% of your users. These users should represent your overall users. Meanwhile, the team observes how these users respond to the new feature before rolling out to everyone else. 

One progressive rollout technique is known as canary deployment. This is where you test how good your feature is on a small group of users and if there’s any issue, you can immediately fix it before it’s exposed to a larger number of users. This sort of gradual rollout helps mitigate the risk of a so-called big bang release. It also helps ease the pressure on your server in case it cannot handle the load.

You may also carry out what is known as ‘ring deployments.’ This technique is used to limit the impact on end-users by gradually rolling out new features to different groups. These groups are represented by an expanding series of rings, hence the name, where you start with a small group and keep expanding this group to eventually encompass all users. 

In a ring deployment, you choose a group of users based on similar attributes and then make the features available to this group. 

Rings and feature flags work together where feature flags can help you hide certain parts of your feature if they’re not ready in any of the deployment rings.

The advantage of such controlled rollouts is the feedback you would generate from users, especially for releases you’re less than confident about and so with the feedback received, you can improve your product accordingly.

Time your launch

We know at this point that feature flags give you the control to release at any time you deem suitable. Feature flags, then, are important because you always decide the ‘when.’ As such, with feature flags, you can aim for a timed launch where you push your feature for people in your trusted circle, such as your QA team, to test in production. 

Afterwards, when it’s time to launch, you simply turn on the feature for everyone else without any fuss with the added advantage that you’re feeling much more confident when it comes to the actual release to everyone else.

This significantly reduces stress among your team because you’ve tested the feature before the official launch and you’ve made sure it’s working as it should before going ahead with a wider release.

Running experiments and A/B testing

Feature flags are great for A/B tests, where you can assign a subset of users to a feature variation and see which performs better.

This is a great use for product and marketing teams who can easily test new ideas and eliminate them if they don’t fulfil the hypothesis defined upon creation of the test.

For example, feature flags would allow your product and marketing teams to send 50% of users to the new variation of a feature and the other 50% to the original one to compare performance according to the goals set and see which variation runs better according to the KPIs set.

Using feature flags to run A/B tests is particularly useful when a feature receives enough traffic to generate efficient results. So, as a cautionary note, keep in mind that not everything can be an A/B test when it comes to feature flags.

In this sense, you can look at feature flags like a light switch. You decide when you want to turn on the feature, when to turn it off and which users have access to it. This allows you to continuously test in production until you’re satisfied with the end-result which you can then roll out to the rest of your users.

Continuous integration and continuous delivery

Feature flags means developers no longer need multiple long-lived feature branches which more often than not lead to merge conflicts.

Let’s imagine you are all set to release but then one developer’s changes have not yet been integrated into the main feature branch. Does this mean you need to wait especially when you know time is precious when it comes to releasing to impatient customers in this day and age?

With this method, developers can integrate their changes, or commit code in small increments, much more frequently, perhaps even several times a day. Through trunk-based development, a key enabler of continuous integration, developers can merge their changes directly into the master trunk helping them move faster to ensure that code is always in a ready-to-be-released state. 

Consequently, we can deduce that feature flags also facilitate the process of continuous delivery.

Feature flags are essential to maintain the momentum of CI/CD processes because as mentioned, feature flags decouple deployment from release so even unfinished features can be merged but can easily be hidden behind a flag so users don’t see it while other changes can still be delivered to users without waiting on those unfinished features.

In other words, feature flags will still allow you to still continuously deploy your code so even if there is an incomplete feature, users won’t be able to access the functionality as it would be hidden behind a flag.

Read more: Feature flags and CI/CD: Increased velocity and less risk

Managing access: User targeting

You don’t just choose the when, you also choose to whom.

Feature flags, as we’ve seen, gives you a lot of control over the release process by putting the power of when to release in your hands. 

It‘s worth mentioning yet another form of power feature flags can give you, which is the ability to choose which users can access the feature. When you are testing in production, having the option to choose who you want to test on is extremely valuable depending on the kind of feedback you’re seeking.

Giving early access

We’ve seen in canary deployment that sometimes the sample you pick can be completely random. Other times, however, you might decide to carefully handpick a select group of users to give them early access to your new feature.

Why is this important? Because these are the users that are considered to be ‘early adopters.’ They are users you trust and whose feedback is top priority and who are most interested in this particular feature. These users are also the most forgiving should anything go wrong with the release.

With feature flags, you can release the feature to these early adopters who are more than willing to provide the kind of feedback you need to improve your product. This technique works well if you have a very risky release that you’re hesitant to release to a wider audience.

Power to the users: beta testing

Beta testing is another side to early access where in this scenario users willingly opt-in to test out your new features before they are released to the rest of your users.

As a result, the customers who opt-in get to see and test the feature by turning it on in their accounts and should they wish to back out they can easily disable the feature, which makes these users more inclined to opt-in in the first place as it makes them feel more in control.

This is an important use-case because it shows your customers that you’re really listening to their feedback by asking them to test your release. 

The users who opt-in are those who you’re targeting with this feature so how they react to the feature will be of extreme use to you. Hence, you get to test out your new feature and you deliver value to your customers by responding to their feedback; it’s a win-win situation!

Dogfooding

This term refers to eating your own dog food, or in this case refers to an organization using its own product or service. You can, therefore, look at it as a way to test in production on internal teams. 

It’s a form of alpha testing that you can run on internal users (within the organization) to make sure that the software meets all expectations and is working as it should. Thus, it represents an opportunity to evaluate the performance and functionality of a product release as well as obtain feedback from technical users.

This is a great way of testing to obtain meaningful feedback especially when you’re introducing new features or major changes that you’re not fully confident about. 

This way, you are taking less risks because it’s only people within your organization who can see the releases as opposed to your actual, external users who may be more unforgiving in case things take a bad turn during a release.

No trespassing allowed: blocking users

Just as you can pick users who you want to access your feature, you can also block users from seeing it. For example, you can block certain users from a particular country or organization.

What feature flags would allow you to do is hide some features from users who might not give you the right sort of feedback while giving access to the relevant target consumers who would be most impacted by the new feature. You can also target certain features for a certain type of user to provide a more personalized experience for them.

Managing entitlements

With feature flags, you can manage which groups of users get access to different features. This is especially common in SaaS companies that offer various membership plans and so with entitlements, you can dictate which features each plan can access. This way, you would be offering different experiences to your users.

Let’s take the example of Spotify. Spotify offers free and paid plans. With the free membership, you can stream music but with advertisements while with the premium membership, you can stream unlimited music with no ads. You also get unlimited skips and you can download music to listen to offline. There are also different levels of premium to choose from including student and family plans. Consequently, with each plan, you are entitled to different content and features.

With feature flags, you can wrap a flag around a feature and release it to a particular customer depending on their subscription plan. These types of flags are usually referred to as permission toggles. They also allow you to move features easily between the different plans i.e. paid and free versions, for example.

Managing entitlements is considered to be an advanced use case as it requires careful coordination across teams and involves working with multiple flags to control permissions for the features. The person who manages entitlements is usually on the product team so careful planning and monitoring of each change performed by which person is required. 

There should also be a seamless process in place to move users from one plan to another. Thus, this use case requires vigilant implementation.

Product demos and free trials

On a similar note, product and sales teams may be looking for a way to offer prospective customers a demo or a free trial or specialized demo of a feature.

Feature flags are a great way to give prospects temporary access to certain features under various pricing plans to give them a taste of through a live demo of the features among the higher plans so they can decide if an upgrade is worth it by simply toggling these features on with a flag then turning it off once the demo is complete. 

Risk mitigation

Test in production

Through the use of Feature flags, teams can confidently ship their releases by testing code directly in production to validate new features on a subset of users.

Unlike testing in a staging environment, when you test in a production environment, you can collect real-world feedback from live users to ensure that teams are building a viable pipeline of products.

Testing in production also allows you to uncover any bugs that you may have missed in the development stages and discern whether your new feature can handle a high volume of real-world usage and then optimize your features accordingly.

Feature flags and mobile app deployment: Bypass app store validation

This is when we use A/B testing to test different experiences within mobile apps. Imagine you’ve just released a brand new app or introduced a new shiny update to your app.

How can you make sure your app or this update is running smoothly or that you haven’t unintentionally introduced an update full of bugs that crashes on your users? Anything that goes wrong will involve a lengthy review process that will setback your entire release as you attempt to locate and resolve the issue.

You no longer need to wait for app store approval, which could take some time and the changes are released to all users instead of smaller segments.

Instead, with remote config implemented through feature flags, any changes can be made instantly and remotely and then released to a small subset of users to get feedback before releasing it to everyone else. Therefore, you can upgrade your app continuously in real-time based on feedback from your users without waiting on app store approval.

It’s also a good way to personalize experiences for different types of users rather than creating a unified experience for all users depending on the demographics you set forth. 

As a result, with feature flags, you can roll out different versions of your mobile app to monitor their impact by releasing different features to different groups of users. Afterwards, you can decide on what features will be incorporated in the final release of your app.

Using feature flags to test out your mobile app is an excellent way to generate buzz around your release by giving exclusive access to a select number of users.

Kill Switch: Feature rollback

Using feature flags will allow you to disable a feature if it’s not working as it should. This is done by using a kill switch. Thus, whenever anything goes wrong in production, you can turn it off immediately while your team fixes the issue. This would prevent you from having to roll back the entire release so other changes can be deployed and released without worrying about delaying the whole release.

With a kill switch, you can switch off a specific, troublesome feature so you can decrease the number of users who can see it, including turning it off for all users if necessary until the issue is analyzed and resolved by your team. This way, you won’t have to go through the entire code review process to locate the issue.

Kill switches therefore give you even more control over the release process. This not only empowers your team of developers but also marketing and production teams with no software development experience who can now easily test in production and kill a feature without having to rely on engineering support.

AB Tasty offers an automatic rollback option that enables you to stop the deployment of a feature and to revert all the changes that have been made in order to ensure that your feature isn’t breaking your customer experience. This is done by defining the business KPI you want to track that would indicate the performance of your feature. If it reaches a certain value, the rollback is automatically triggered.  

Sunsetting features

Feature flags can also enable the ‘sunsetting’ of features. For example, with time, you might see your usage of feature flags increasing and widening to encompass a number of features. However, this accumulation of features may eventually turn into a heavy debt. 

This is why it is important to continuously keep track of which features you are using and which features have run their time and need to be retired from your system.

Sunsetting, then, enables you to kill off features that are no longer being used. Feature flags would give you an idea of the usage of certain features which would help you determine whether it’s time to kill it off, lest you end up with the dreaded technical debt.

Removing unused features and clearing up old flags is the best way to keep such hidden costs in check. Thus, you should have a careful plan in mind to remove some flags once they have served their purpose or otherwise you end up with the aforementioned technical debt. This will require you to have an efficient feature flag management system in place to track down ‘stale’ flags.

Managing migrations

Feature flags can be used to safely and effectively migrate to a new database as business requirements change and evolve. What organizations would normally do before feature flags is a one-time migration then hope for the best as rollbacks are usually a painful process.

Obviously, the biggest risk that comes with switching databases is loss of data. Therefore, developers need a way to test that the data will remain intact during the migration process. 

Enter feature flags. They allow you to facilitate migration and should something go wrong, you can disable the migration by simply toggling the flag off.

A percentage rollout can then be implemented using feature flags to validate the new database and any changes can be reversed by using feature flags as a kill switch.

Read more: How to migrate from monolith to microservices architecture using feature flags

Feature flags as circuit breakers

Feature flags are particularly useful when your system is experiencing heavy load during times of exceptionally high traffic. 

In particular, the on/off switch of feature flags (operational toggles) can be used as circuit breakers to disable non-critical features that add stress to the system to help your website run better and avoid any backlash from any potential downtime caused by a heavy load. 

For example, many e-commerce websites experience heavy traffic during Black Friday. To avoid a potential system outage or failure, development teams can use feature flags to turn on critical features and turn off the rest until this period of heavy traffic passes to shed some of the load from a system.

Bottomline: Use feature flags often but proceed with caution

As we’ve seen so far, many of the use cases can be easily implemented. However, others will require the ability to make detailed, complex and context-specific decisions so a more advanced feature flagging system that enables such functionalities would be needed.

Regardless of what you decide to use feature flags for, one thing is clear: feature flags put you in the driver seat when it comes to releases. You are in complete control of the when and to whom you release. It also allows you to experiment to your heart’s content but without the risks, especially when the release doesn’t go as expected. 

Working with feature flags also increases productivity among teams. As we’ve seen in the use cases outlined above, it’s not only developers who have complete control over and access to the release process but product and operations teams can also release and roll back as needed.

Read more: Feature flags use cases for product teams

You can use features for many things across different contexts. Some may remain for a long period of time while others need to be extracted as soon as possible so as not to accumulate technical debt. 

Thus, the general advice would be to use feature flags often but keep in mind that proactive flag management and implementation will be needed to maximize the benefits while minimizing the costs.

Don’t just take our word for it. Start your feature flag journey and see for yourself what  feature flags can do for you by signing up for a free trial at AB Tasty.

Let’s face it, continuous delivery can put a lot of pressure on technical teams. 

Release cycles are short, workloads are heavy, yet the results must perform optimally. 

A small but powerful technique can help tech teams avoid delivery bottlenecks and safely release new features and that’s through feature flags.

Let’s talk more about feature flagging and how a feature management solution for tech teams can help streamline release processes. 

What are feature flags, and why use them?

Feature flags are part of feature management and enable tech teams to manage a feature throughout its entire lifecycle. 

You can use feature flags to separate feature release from code deployment and to turn features on and off at any time. This gives you full control over the release process allowing you to ship features to subsets of users and avoid the risky big bang release. 

Therefore, there are many benefits to using feature flags, among them include the following three key benefits:

• They are emergency switches. Have you ever seen the red buttons on big machinery labeled “Emergency Stop”? Feature flags are like these buttons for your software. Let’s say a new feature causes damage to your server. The solution: Deactivate the function using its feature flag without having to deploy any code.
• They help reduce risks. Do you have a new idea for a feature but don’t know whether your users will like it? Use a feature flag to enable the feature only for a defined set of users. But there’s more you can do as feature flags can be used alongside a number of deployment strategies, such as canary deployments, beta programs, and A/B testing. They all help ensure a feature’s quality and performance before releasing it to your user base.
• They support continuous delivery. Suppose your next release is imminent. Yet, one of the features is still under development. Sure, you could use complex feature branching and make sure they don’t go into production. But it would be a lot easier to only have the main branch, wrap the unfinished feature in a feature flag, disable it and still deliver your new release.

The role of feature flags in the bigger picture of product development

Some tech teams aren’t sure if the time invested in creating and maintaining feature flags is worth it. 

Yet, feature flags reveal their true potential only when you combine them with other techniques. Thanks to progressive rollouts and server-side experimentation, you can ensure that your product meets users’ needs in the right way. 

In the end, they allow tech teams to do their jobs more efficiently. Developers don’t need to worry about unpleasant surprises and the final ramifications of a release. 

Other teams besides development teams can also reap their benefits as feature flags can be used across a number of use cases to suit each teams’ needs.

This is especially the case when you have an advanced feature management solution which gives all teams more control and flexibility over the release process. 

Why is the need for dedicated feature management solutions rising?

More and more people around the world rely on software for their personal and professional lives. 

The increasing demand also means that more software companies jump into existence, and the market is becoming denser. 

You aim to continuously deliver products, updates, and new features to stay relevant and keep up with your niche competition. However, tech teams need reliable workflows and tools to get the desired results in this fast-paced environment.

While many companies did not have organized release processes in place a few years ago, the situation has changed since then. Today, many use continuous development and delivery to respond to rapidly changing consumer demands.

By integrating feature management techniques, you can further optimize these processes. But how can you use feature flags for your purposes? And how can you combine them with experimentation and progressive rollouts?

Yes, you guessed it: invest in a dedicated feature management solution. You have three options depending on your needs and resources: 

1) Build a tool yourself from scratch

2) Create a platform based on adequate open-source projects

3) Use an existing third-party solution

In theory, you could build the platform yourself. But do you want to burden your tech teams with this complicated task? 

You also need to consider whether you have the right expertise and resources available, and you will have to worry about ongoing maintenance. There’s a lot you have to think about, including the points highlighted below when it comes to the build vs buy debate. 

The next section will look into how opting for an advanced third-party solution can help streamline your teams’ delivery and release processes.

Tackle the challenges of continuous delivery with a feature management platform

The challenges that tech teams have to face on a daily basis are manifold. But what difficulties do these teams meet in their day-to-day work with feature management? And how can a dedicated solution like AB Tasty help them? Let’s find out!

AB Tasty’s flagging functionality eliminates the risks of future releases by separating code deployments from feature releases so you can safely deploy new features anytime to anyone you choose. The platform is packed full of features and was especially built to cater to the needs of both development and product teams. 

Product teams 

Product managers often have great ideas but often, such ideas come with great risk. Feature flags are a great way for product managers and their teams to test out these ideas safely while collecting valuable feedback from real-world users.

In particular, feature flags provide value for product managers in two key ways:

Feature flags & progressive rollouts

You may be familiar with the following situation: Before you release a new feature, you want to test it with QA and a small group of users. 

Since the tests produce good results, you push the new component into production. Unfortunately, the feature and your server configuration don’t play well together. Your server crashes. As a result, you may break SLA agreements with customers, lose money, and damage your reputation.

This is where feature flags can come to the rescue. 

Once you notice the damage, you can disable the malfunctioning feature in seconds – without deploying any code – to avoid any major negative impact. 

However, keep in mind that progressive rollouts can actually prevent this situation from happening in the first place. 

With progressive rollouts, as the name implies, you can progressively release a feature to a specific audience directly from the AB Tasty dashboard by choosing each deployment step and the proportion of traffic allocated to your users.

This way, teams can identify any problems earlier when the feature is still being served to a limited number of users. Then they have the chance to react to this malfunction and avoid application downtime.

Feature flags & experimentation

Let’s imagine another situation. Your customers and stakeholders have a lot of feature requests and feedback on your product. 

But even after you’ve categorized these inputs and boiled them down to a minimum, there are still plenty of different ways to turn them into reality. You’re also not quite sure which solutions will bring the best results. But, you are under pressure to act and have to deliver.

Experimentation helps you master this challenge. 

With experimentation, product teams can compare different variations of features with users to reveal which one has the best positive impact. Afterwards, the better performing variation can be rolled out to the rest of your users.

Thus, experiments are a great way to help product teams to learn and prioritize resources allowing them to focus on what to optimize for the best outcomes.

Feature flags give you more control over the release process by running experiments on developed or modified features with a small subset of live users in order to see whether they’re performing as intended before going for a big bang release.

AB Tasty, in particular, offers server-side experimentation allowing you to run more sophisticated tests and advanced experiment capabilities. You can then conduct safe experiments for your features by setting up user-targeting and KPIs to track putting you on the road to quicker and safer releases.

 

CTOs & IT teams

CTOs want high-performing development teams to continuously deliver high-quality software. They likely have several teams under their wings that they expect to act independently and ensure release quality. 

Modern software contains many feature flags that must be maintained over a long time. But how can CTOs keep track of things? A tool to collaborate with tech teams on release management would help CTOs save time and diminish costly misunderstandings.

Yet, the successful implementation and integration of such a complex tool into the IT landscape can represent a significant hurdle. 

IT teams must have enough resources and expertise. In the long term, they have to spend a lot of time monitoring and maintaining the platform. Apart from that, IT teams already have their hands full with tasks for their company’s digital transformation. 

A dedicated feature management tool brings all teams together on a common platform. 

In this way, you can optimize the release times and minimize risks thanks to more efficient and effective collaboration and feature management. 

Since AB Tasty is a managed SaaS, IT professionals don’t need to spend resources on maintenance. We take care of things for you and develop our server-side solution further so that you can always work with a secure and state-of-the-art solution.

Data teams

For data-driven product development, teams need to access relevant analytics data to check a feature’s performance. 

For example, they need to analyze and assess user behavior in detail after a new feature has been integrated into a product. When testing new features, they need to activate and deactivate them and control what to test when and with whom. 

Unfortunately, it is often impossible to simulate an identical copy of the production environment. This leads to inaccurate results, and lets teams make imprecise data-driven decisions.

With AB Tasty, data teams can comfortably analyze feature performance in a visual dashboard, set goals, and track them with real-time reports. 

This way, they can ensure that the results align with business goals and find new ways to improve the product. 

Finally, feature flags and progressive rollouts eliminate the need for staging servers and prevent inaccurate data. As a result, data teams can fruitfully improve the software by making appropriate data-driven decisions.

Development teams

Software developers should focus on building functionality, not fixing bugs from previous versions, and doing rollbacks.

Working with feature flags can also be very time-consuming, as software engineers shouldn’t lose track of the flags’ status. Moreover, the risk of unnecessary errors creeping into the software increases when working with large teams. As a result, developers may be discouraged from using feature flags due to the time pressure and perhaps no longer use them at all. 

Additionally, bottlenecks in development can affect release times. Poorly structured release processes can also hinder development by preventing engineers from developing new features. 

Finally, if there’s no suitable solution, these issues can affect the duration and regularity of release cycles.

Hence, development teams need a framework that allows them to enforce feature flag best practices, stay in control, and collaborate effectively with team members. 

We understand that feature development and feature releases are two sides of the same coin. As a result, AB Tasty aims to bring teams closer together by collaborating on common matters in a shared tool. 

To do this, they have access to all essential feature management tools by default. So there’s no need to invest manpower in building a solution themselves. We also make things easier for them by providing a visual dashboard for creating and managing feature flags with simple clicks – no code deployments required.

And since we have developed our server-side tool for developers, we offer them everything they need to work with the tool including:

• Easy-to-use SDKs 
• Comprehensive documentation 
• API references 
• Other useful developer resources like this blog

QA & release teams

Without proper workflows, tech teams struggle to conduct controlled releases and experiments. DevOps spend a lot of time managing staging servers and keeping their configurations similar to production. Nevertheless, there’s a higher risk that tests run on staging servers will yield inaccurate results that lead to incorrect conclusions.

Yet, QA specialists and DevOps teams rely on A/B tests, canary releases, and beta programs to ensure that they deploy high-quality features securely. Often they don’t know about the current status or the use of a feature flag in the code either. Especially if they don’t have access to an overview of existing feature flags. As a result, it gets trickier to keep track of ongoing tests and deployments, and who can see which features at what times.

We designed our feature flagging platform to meet today’s demands for fast and continuous delivery. Our solution enables tech teams to collaborate in one place, monitor issues, and control each deployment in a visual dashboard. Release teams can thus keep full control over deployments and take full advantage of progressive rollouts.

Additionally, DevOps teams can focus on more important things than managing staging servers. That’s because AB Tasty eliminates the need to use these environments in the first place. Using feature flags in production, QA can always see how a feature works in its real-world environment and get accurate test results to work with.

The power of feature flags is at your fingertips

Feature flags are an integral part of modern product development, including experimentation and progressive rollouts. This simple technique is vital if you want to provide stable, high-quality functionality to your users.

Using a feature management solution, your tech teams can use a single tool to streamline workflows and communication. Regardless of a team’s tasks or focus, our feature management service has everything it takes to deliver the right features in the right way.

If you’re looking to get started on building an application, you may be wondering whether to design it as a monolith or build it as a collection of microservices. In fact, this has been a long-standing point of debate for many years among application architects.

So what is the difference between these two architectures and how do you decide which one to choose and which one is best for your organization?

While monolithic architectures have been used for many years, microservices seem to be taking over as it’s becoming a key driver of digital transformation.

Indeed, in a world where speed and agility are more important than ever, you may find that switching over to the more versatile microservices approach to build applications that are quicker to create and deploy the go-to-strategy to remain competitive and to be able to continuously deliver software without delay.

In this post, we will investigate the above questions by comparing monolithic and microservices application architectures to help you in your decision. We will also explain, since moving to microservices might be a risky endeavor, how feature flags may help reduce some of that risk.

Monolithic architecture

Before we move on to the migration process, we will quickly go through the definitions of these architectures and why one may take precedence over the other.

By definition, a monolith refers to a “large block of stone”. In the same way, a monolithic application is an application made up of one piece or block built as a single indivisible unit. 

In that sense, in a typical monolith application, code is handled in one single, tightly knit codebase and so data is stored in a single database. 

Although this type of application is considered to be the common and traditional method to build applications, it may cause some major problems and over time may become unmanageable. 

The image below illustrates the makings of this architecture, which consists of a client-side user interface, server-side application and a database. They all function as a single unit and so changes are made in the code base and require an update of the entire application.

Below, we will list some of the difficulties and drawbacks associated with this architecture, which prompts many to move to microservices.

Drawbacks of monolithic applications

• Less scalability- components cannot be scaled independently; instead, the whole application will need to be scaled, not to mention that every monolith has scalability limitations. 

• Reliability issues- given how the components of a monolithic application are interdependent, any minor issue may lead to the breakdown of the entire application.

• Tight coupling- the components of the application are tightly coupled inside a single execution meaning that changes are harder to implement. Furthermore, all code changes affect the whole system, which could significantly slow down the development process.

• Flexibility- with monolithic applications, you will need to stick to a single technology as integrating any new technology would mean rewriting the entire application which is costly and time consuming.

• Complexity- as a monolithic application scales up, it becomes too complicated to understand due to how the structure is tightly connected and becomes even harder to modify that eventually it may become too difficult to manage the complex system of code within the application.

Despite its drawbacks, monoliths do offer some advantages. Firstly, monolithic applications are simple to build, test and deploy. All source code is located in one place and can be quickly understood. 

This offers the added advantage when it comes to debugging. As code is one place, any issues can be easily identified to be fixed.

As already mentioned, a monolithic approach has been in existence for a long time and since it’s become such a common method for developing apps, this means that engineering and development teams have the sufficient knowledge and skills to create a monolithic program.

Nonetheless, the many disadvantages of monolithic architecture has led to many businesses shifting to microservices.

Microservices architecture

Unlike a monolithic architecture, microservices architecture divides an application into smaller, independent units and breaks down an app into its core functions-each function is called a service. 

Every application process is handled by these units as a separate service and each service is self-contained; this means that in the event that a service fails, it won’t impact the other services.

In other words, the application is developed as a collection of services, where each service has its own logic and database and the ability to execute specialized functions. The following image depicts how this architecture works:

You can look at each microservice as a way to break down an application into pieces or units that are easier to manage. In the words of Martin Fowler:

In other words, microservices architecture is a way to design software applications as suites of independently deployable services that communicate with one another through specific methods, i.e by using well-defined APIs.

Microservices: The answer to accelerated application development and time to market?

More distributed systems architectures such as microservices are increasingly replacing the more traditional monolithic architecture. One of the main reasons is that systems designed with microservices architecture are easier to modify and scale.

Due to its distributed nature, developers can develop multiple microservices simultaneously. 

Since services can be deployed independently, each service is a separate codebase that can be managed by a small development team, as can be seen in the image below, which illustrates the major differences between these two architectures: 

This results in shortened development cycles so releases are ready for market faster.

Microservices, as a result, are used to speed up the application development process as this type of architecture enables the rapid delivery of large, complex applications on a frequent basis. 

Moreover, since these services are deployed independently, a team can update an existing service without redeploying the entire application unlike monolithic architecture. This makes continuous deployment possible. 

This also makes these types of applications less risky to work with than monolithic applications. Risk mitigation, then, is one of the key drivers for adoption of microservices.

This makes it easier to add new changes or functionalities to it than to a monolithic program. This means that updating the program is more straightforward and less troublesome.

With monolithic applications, even the most minor modifications require redeployment of the entire system and so feature releases could be delayed and any bugs require a significant amount of time to be fixed.

Thus, microservices fits within an Agile workflow as using such an approach makes it easier to fix bugs and manage feature releases. You can update a service without redeploying the entire application and roll back if something goes wrong.

Not to mention that a microservices architecture addresses the scalability limitations that come with monolithic architecture. Because of its smaller, autonomous parts, each element can be scaled independently so this process is more cost- and time-efficient.

Finally, each service can be written in a different language without affecting the other services. Developers are also unrestricted by the technology they choose so they can use a variety of technologies and frameworks instead of going for a standardized one-size fit all approach.

To sum up the differences…

The table below summarizes some of the major differences between the two architectures:

	Monolithic	Microservices
Deployment	Simple deployment of the entire system	More complex as there are independent services which need to be deployed independently
Scalability	Harder to scale; the whole system needs to be redeployed	Each element can be scaled independently without downtime
Testing	Easier to test: end-to-end testing	Harder to test; each component needs to be tested individually
Flexibility	Limited to single technology	Freedom of choice of tech stack
Security	Communication with a single unit and so security is handled in one place	Large system of standalone services communicating via network protocols raises security concerns
Adoption	Traditional way to build applications so easier to implement and develop as developers possess necessary skills	Specialized skills are required
Resiliency	Single point of failure- any issue can cause a breakdown in the entire application	A failure in one microservice doesn’t affect the other services

Tread carefully with microservices

In sum, a microservices architecture offers many advantages. Nonetheless, this type of architecture may not be suited for all companies so a proper evaluation will need to be made to choose the best approach for them depending on factors such as type of product or audience.

As a result, before moving onto the migration process, it is important to proceed carefully before attempting this migration as a microservices architecture is not without its cons. 

Among some of the drawbacks of microservices include:

• We’ve already mentioned how monolithic architectures have been used for a long time that many engineering teams have the knowledge and experience to create a monolithic program. Meanwhile, building a microservice application without the necessary skills could be a risky endeavor as a microservice architecture is a distributed system and so you would need to configure all the modules and database connections.

• Just a monolithic application could become complex with time, standalone services that make up a microservice application could also lead to high developmental and operational complexities.

• Because of the distributed system that makes up this architecture, testing such an application is more difficult because of the large number of deployable parts.

• Debugging and deploying these large numbers of independently deployable components are also much more complex processes. (However, should any individual microservice become unavailable, the entire application will not be disrupted).

• Testing, such as integration and end-to-end testing, can become difficult due to its distributed nature. This is in contrast to monolithic apps which consist of a single unit that makes it easier to run end-to-end testing.

In the end, transitioning to a microservices architecture will ultimately depend on the pain point you’re trying to solve.

You’ve got to ask yourself whether your current (monolithic) architecture is giving you trouble and whether actually migrating to microservices will help solve your issues.

Make the transition less risky: Feature flags and microservices

With the above in mind, DevOps teams might still want to make the transition from monolithic to microservices architecture due to its compatibility with Agile development workflows, that come with with lower risks and fewer errors.

During this process, teams will look to replace the old code and roll out the new code at once, which could be very risky.

Therefore, migration to a microservice-based ecosystem could turn out to be a challenging and time consuming process, especially for businesses with large and complex systems with monolithic architecture.

This is where feature flags come into play.

Feature flags are a great asset when it comes to releases and we’re not only referring to front-end releases but also when it comes to your architectural strategy.

Feature flags give you greater control over the release process by choosing when and to whom you will release products and features by separating deployment from release.

Thus, you can turn features on or off for certain users by simply wrapping them up in a feature flag without redeploying, lessening the risk associated with the release process.

Just as feature flags enable progressive delivery of features instead of a big bang release, the same idea applies when it comes to migrating to services: it’s best to do it one piece at a time instead of all at once. 

The main idea is to slowly replace functionality in the system with microservices to minimize the impact of the migration.

You would essentially be making small deployments of your microservices by deciding who sees the new service instead of going ahead with a big bang migration.

This will be preceded by analyzing your current system to identify what you can start to migrate. You can experiment with functionalities within your customer journey to start migrating and gradually direct traffic to it via feature flags away from your monolith and then slowly kill off the old code. 

There are other ways to go about the migration process- which often involve a roll out of the new code all at once- but feature flags lessen the risk usually associated with microservices releases through progressive rollout instead.

Split your monolith into microservices using feature flags

The key is to move from monoliths towards microservices in incremental ways. Think of it as if you’re untangling a knot that’s been tightly woven together and feature flags as the tools that will help you to gradually unravel this knot.

• Start with identifying a functionality within your monolith to migrate to a microservice architecture. It could be a core or preferably an edge functionality such as a code that sends coupon or welcome emails to users in the case of an e-commerce platform, for example.

• Proceed by building a microservice version of this functionality. The code that controls the functionality within the monolith will need to be diverted to where the new functionality lives, i.e within the microservice.

• Then, wrap a feature flag around this microservice with the traffic going to the old version. Once the feature flag is turned on, the microservice code is turned on so you can direct traffic to the new version to test it.

• Note that you should keep the existing functionality in place in the monolith application during the transition so you can then alternate between different versions or implementations of this functionality-the one in the monolith and the one in the new microservice.

• If anything goes wrong, you will be able to revert traffic back to the monolith with the original functionality. Hence, you can switch between the two functionalities until you’re satisfied that the microservice is working properly.

• Using a dedicated feature flag management tool, you can test the microservices to ensure everything is working as expected. Feature flags allow you to target certain users such as percentage rollouts (similar to a canary deployment), through IP address or whatever other user attributes you set. 

• If no issues come up, then you can turn the flag on for more users and continue to monitor the microservice to ensure that nothing goes wrong as you increase the traffic to it.

• Should anything go wrong, you can roll back by turning the flag off (i.e kill switch) and delete the old application code.

• Make sure you remove the flag once you no longer need it to avoid the accumulation of technical debt.

• Then, you will repeat this process with each functionality and validate them with your target users using your feature flag management tool.

Remember, the whole point is to create these microservices progressively to ensure things go smoothly and with feature flags, you further decrease the risk of the migration process.

This is based on the idea of the ‘strangler fig’ pattern. 

This term is inspired by a kind of plan, where in a similar way to the plant, the pattern describes a process of wrapping an old system with a new one, the microservice architecture, using an HTTP proxy to divert calls from the old monolith functionality to the new microservice.. 

This would allow the new system to gradually take over more features from the old system, as can be seen in the image below, where the monolith is ‘strangled’: 

In this scenario, a feature flag can be applied to the proxy layer to be able to switch between implementations.

Conclusion

Monoliths aren’t all bad. They’re great when you’re just getting started with a simple application and have a small team; the only issue comes from their inability to support your growing business needs.

On the other hand, microservices are a good fit for more complex and evolving applications that need to be delivered rapidly and frequently and particularly when your existing architecture has become too difficult to manage. 

There is no one-size fits all approach. It will eventually depend on the unique needs of your company and the capabilities of your team.

Should you decide to take the plunge and shift to microservices architecture, make sure that you have a feature management tool where you can track the flags in your system and how your features are performing.

AB Tasty’s server-side functionality is one such tool that allows you to roll out new features to subsets of users and comes with an automatic triggered rollback in case something goes wrong during the migration process. 

The most important takeaway is to carefully consider whether you really need to migrate and if so, why. You must evaluate your options and think about the kind of outcome you’re hoping to achieve and whether a microservices architecture provides the right path to this outcome.