Microservices Vs. SOA: What’s the Difference?

What’s the difference between microservices and SOA? The two design paradigms have a lot in common.

That makes sense when you consider that microservices are an offshoot of the SOA movement. But there are essential differences between the two systems. Let’s take a look at the two different approaches to architecture and highlight where they differ.

Before we dive in, it’s important to note that neither architecture has a universally accepted definition. So, you could spend as much time debating the details of what microservices or SOA are as you could arguing their differences.

What’s a Microservice Architecture?

Search for “what are microservices?” on the internet, and you’ll see many different definitions. So, let’s factor in the common attributes and look to an expert for some help with defining them.

A microservice architecture builds applications with loosely coupled services. Each service has a single responsibility. So, they focus on one task, such as authentication, billing, or inventory.

Martin Fowler’s Definition

Here’s a concise definition from Martin Fowler and James Lewis.

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” – James Lewis and Martin Fowler

There’s a lot packed into that paragraph. Let’s take a look at four of the main points in this definition.

Loosely Coupled and Loosely Managed

Each service runs in its own process. Many web applications used to run as a single server. So, services running in separate processes are an important break from the past. But the Wikipedia definition of microservices says that they can run in the same process. This illustrates how hard it is to nail these definitions down.

We build microservices around business capabilities. Whether or not a service runs in its own process seems like an academic argument. What the code does is where the rubber hits the road. We build microservices around specific business capabilities, and that’s what puts the “micro” in them. The service focuses on a particular responsibility within the broader application. The number of lines of code and the process footprint isn’t what makes them small.

We deploy and run microservices independently. Microservices stand alone, and we can install and run by themselves. Development teams are also independent, so they can develop applications with tools and languages that are distinct from other services in the same application. The teams also use continuous integration and automated testing.

We deploy microservices with limited centralized management. Microservices architectures have limited and decentralized governance. So, development teams have a lot of autonomy. They manage their schedules, and different parts of an application are deployed at different times. Teams select their platforms, languages, and tools. As we’ll see, this is one of the areas it departs significantly from SOA.

What’s Service-Oriented Architecture?

There’s no single definition of SOA. It’s been around for a long time. Several major software vendors embraced it in its heyday, so the architecture tended to have different definitions depending on where you looked. Thirteen years ago, Fowler wrote an article titled ServiceOrientedAmbiguity where he concludes “I think SOA has turned into a semantics-free concept that can join ‘components’ and ‘architecture.”

The Open Group Definition

But there is a definition from The Open Group. This industry group defines the UNIX trademark, the TOGAF architectural standard, and SOA. The SOA standards page is here. You have to create an account before you can download PDF versions of their document. So, we’ll go to the Wayback Machine and get the page where they used to share their SOA definition for free.

The SOA definition is longer than the one I used for microservices. So, I’m only going to provide a couple of excerpts here.

Service orientation is a way of thinking in terms of services and service based development and the outcomes of services.

A service:

  • Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
  • Is self-contained
  • May be composed of other services
  • Is a “black box” to consumers of the service

So far, we can see a lot of overlap between microservices and SOA. The first two bullets work with Fowler and Lewis’ definition of microservices.

But, the third is where things start to diverge. Can you build a new service by combining two others and still call it a microservice? Probably not. The combined services are no longer independent. So, we can see where SOA and microservices are not the same things.

Meanwhile, the last point is just good design. A service that requires knowledge of its implementation is an anti-pattern. I’m surprised that item made it past the committee.

SOA and Centralized Governance

Open Group’s architectural style list implies that it contains “must have” features. Let’s look at a few salient points.

  • Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
  • It requires strong governance of service representation and implementation.

The standard mentions service orchestration and states that if your architecture doesn’t use it, it’s not SOA. This requirement runs directly against how Fowler and Lewis describe microservices. Service orchestration implies the kind of synchronization and coupling between services that microservices do not have.

They also clearly state that SOA requires strong governance.

So, from just a brief look at a definition of SOA, we see clear differences with microservice architecture.

Microservices Vs. SOA: What Are the Differences?

Centralized Management

First, let’s start with the obvious difference. The SOA architecture requires strong governance, while microservices do not.

Fowler and Lewis dedicate a section of their post to decentralized governance and data management. Microservice teams work independently. They manage their schedules and work with the tools they wish. They maintain control over how they represent business objects and make their own data storage decisions. Fowler presents this as an advantage. When you read the description of how the teams operate, you can’t help but think of an agile program.

The Open Group requires strong governance in SOA. They have a standard for SOA governance here. (PDF here.)

Here’s a quote:

As a discipline, governance has been with us for many years, but with the advent of enterprise SOA, the need has been heightened for organizations to take governance as a discipline more seriously.

The standard implies that we need to tighten oversight for service-oriented architecture, not loosen it. A quick scan of the standard brings to mind daily status meetings, launch checklists, and quarterly software releases.

Independent Services and Service Orchestration

We think of microservices as independent entities. They are loosely coupled, if coupled at all, and employ their own messages and domain logic. Fowler refers to this as smart endpoints and dumb pipes.

The SOA standard specifically mentions service orchestration. If you dig deeper, you find discussions of messaging. Services using a message bus to communicate with each other. Many SOA implementations use an enterprise service bus to coordinate activities between services.

This is where the two architectures have their most significant differences. If SOA services are going to communicate across a shared bus, they need centralized governance, even if it is not necessarily as rigorous as the one spelled out by the Open Group. They have to agree on how to represent business objects and the domain logic that manipulates them.

Microservices exist in silos and, if implemented with Fowler’s smart endpoints and dumb pipes evolve independently.

Microservices Vs. SOA: Why Should I Care?

So, it turns out there’s a difference between these two architectural patterns, and it’s a significant one. Microservices stand alone, with decentralized management. Development teams can work independently, and with the tools they choose. Fowler at least implies a direct connection between agile methodology and microservices

Meanwhile, an application built with SOA is composed of services that are more closely coordinated than with microservices. This means establishing governance in advance, and often requires that development teams use the same tools.

Is one paradigm better than the other? I don’t think so. While the decentralized management and isolation of microservices are inherently attractive, some problem domains can benefit from services that communicate with each over a backplane.

The question you should really be focused on is, do you know how your system is designed, and why?

This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)

Java 12 Switch Expressions

Oracle will release Java 12 in March and it comes with a handful of new features. I’m going to cover them in the next few posts. We’ll start this week with switch expressions. I’ll take a look at how they change how you’ll use the language.

A Basic Class

Let’s start with a simple car class.

Car has an enum that indicates whether it’s a standard, deluxe, or limited model. We’ll going to use this flag to manage the car’s different features.

Standard Switch Statement

So, it makes sense that we’d use a switch statement to manage features.

Let’s set up a method to set the number of cylinders based on the model:

We could write this without the local cylinders variable, of course. I started with an example that uses break statements to demonstrate a typical switch.

Here’s a simplified version:

Without the local variable, we need a default case to be sure a value is returned from the method.

Either way, switch statements are a little noisy.

Java 12 Switch Expressions

Java 12 makes this easier to write. You can use a switch expression:

As the name implies, this new switch is an expression, not just a statement. It returns a value. So, the question of whether to use a local variable when selecting a case goes away.

It’s also much easier to read since we don’t need breaks, and each case fits on a single line.

But, you can still use multiple lines in a case if you need to. Let’s say you want to add another field to Car and use it to change the result of getCylinders(). You can add a code block inside the case, and use a break to return a value.

Even though this adds a couple of break statements, it’s still cleaner and easier to follow than a switch statement.

I’m looking forward to moving to Java 12. Stay tuned for more!

Photo by Karim MANJRA on Unsplash

The Pitfalls of C++

Here’s a post I wrote about my other working langauge, C++. You can find the original over on Typemock.

There’s an old expression developers use when someone makes a mistake. They say you “shot yourself in the foot.”

There’s a variation on the joke that describes the experience of shooting yourself in the foot in various programming languages. The descriptions have evolved, and some versions are funnier than others. But the C++ gag has remained the same since I first saw it, back when I was still wrestling with Rogue Wave Tools.h++, and the STL was only an unsubstantiated rumor. Here is one example:

You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can’t tell which are bitwise copies and which are just pointing at others and saying, “That’s me, over there.”

C++ lets you do just about anything.  If you can convince the compiler that you’ve written legal code, it will compile it. Of course, this means that you can, well, shoot yourself in the foot. Let’s take a look at some of the pitfalls of C++.

We’ll define a pitfall as a bug that compiles but doesn’t do what you expect. There’s quite of a few of these bugs, but we’ll cover a handful.

Overriding Arguments in Virtual Functions

Let’s start with an example of a C++ pitfall with virtual functions.

Consider two classes. One is a subclass of the other.

Next, we have a mainfunction that accesses the subclass via a pointer to the base.

Now, when we run the program, we see this:

That’s what we expect. When we access a subclass via a pointer to its base class, we expect the subclass’ version of a function to be executed.

But we can break this without even trying hard.

Now, let’s add a default argument to Bar’s implementation of doit().

Then, run the program again.

Oops! C++ gave us the implementation of doit() we deserved, but not the one we needed. It ran Foo’s version of doIt() because it has no arguments.

This is a contrived example. Most developers wouldn’t overload a method and add a new default argument at the same time.

But, what if we don’t add a default argument, but change an existing one in a subclass?

First, let’s make a few changes to our two classes.

Next, run this new version of our test program:

We got the right method, but the wrong default value.

Well, we did get the right one because the compiler is always correct, even when it’s wrong.

Default parameters are trouble, and you’re best off avoiding them. But if you do need them, remember that they’re part of the function signature and affect how the compiler picks methods.

Virtual Destructors

Smart pointers have made working with C++ easier. There’s no reason to worry about memory management anymore, right?

Not so much. Let’s add destructors to our classes.

Next, let’s allocate a Bar on the heap, use it, and then clean it up with delete.

Now, give it a spin.

Since we deleted our Bar instance via a pointer to Foo, and Foo’s constructor isn’t declared as virtual, the compiler called instead of the override. This can lead to leaked memory.

If you plan on using polymorphism, declare your destructors virtual.

So let’s make Foo’s destructor virtual and re-run the code.

That’s more like it!

Here’s a good rule of thumb: if you plan on subclassing a class, make the destructor virtual. If you don’t, make it protected, so if someone tries to create a subclass later, the compiler will refuse to build the code.

Also, don’t create a subclass if you’re not sure that the base class has a virtual constructor. If in doubt, use composition instead of inheritance.

Deleting Arrays

We need an array of Bars.

If you’ve been coding with C++ for a while, you might see the error right away. We should delete arrays with delete[], not delete.

This code compiles. If you run a debug build, it may stop with an exception, depending on your platform. A release build may run normally, or it may exit with an error.

Here’s what I got with CLion running in Windows:

Destroying a Bar
Destroying a Foo

Process finished with exit code -1073740940 (0xC0000374)

So, it exited with an error. This bug might not make it past unit tests or integration tests.

We hope.

How do you avoid this? Easy. Use a vector. Problem solved. C++’s primitive arrays are an accident waiting to happen since they act like raw pointers.

Class Members in Initialization Lists

Initialization lists are the preferred way to set up a new class instance’s state.

Here’s an example:

Let’s try this class out with this code in main.

Our output looks like this:

The compiler didn’t initialize the _length member correctly.

Class members are initialized in the order they are declared, not the order specified in your initialization list. Since it’s defined first, _length was initialized with the value in _capacity. But _capacity wasn’t initialized yet.

Don’t refer to class members in initialization lists, no matter how neat and concise it looks.

This is another mistake that your IDE and your static analysis tools should warn you about. But the code will still compile. It might even work sometimes.

Calling Virtual Functions in Constructors

Let’s finish up with a constructor pitfall.

First, simplify Foo’s constructor.

Next, edit Bar so it only overrides the status() method. We don’t need a new constructor.

What happens when we create a Bar?

When status() is called, our type is still Foo. So, its version of the virtual function is called.

Don’t call virtual functions in constructors.

Ignoring Your Tools

We have one more C++ pitfall to look at before we’re done.

Two of our pitfalls required ignoring the signs before we fell into the hole. When we deleted an array with the wrong operator and tried to initialize a member with another uninitialized member, both Visual Studio and CLion warned us. (I’m assuming Eclipse would have too.)

Pay attention to your tools. Run static analysis. Turn on your compiler’s warnings and tell it to treat them as errors. Your feet will thank you.

Watch Your Step

It’s possible to code in C++ without steel-toed shoes and a doctor on standby. Both the language and the tools have come a long way in the past decade, and it’s possible to get C++’s superior performance and write clean code that’s stable and easy to maintain at the same time.

TypeMock’s Isolator++ is one of those next-generation tools. You can use it to quickly put together effective tests for your legacy and your new code. Download a trial for Linux or Windows today. Your toes will thank you.

How to Merge Log Files

I mentioned how much I enjoy working with Python last week. Here’s another post where I used it to solve a company sysadmin problem.The original post is over here.

You have log files from two or more applications, and you need to see them together. Viewing the data together in proper sequence will make it easier to correlate events, and listing them side-by-side in windows or tabs isn’t cutting it.

You need to merge log files by timestamps.

But just merging them by timestamp isn’t the only thing you need. Many log files have entries with more than one line, and not all of those lines have timestamps on them.

Merge Log Files by Timestamp

Let’s take a look at the simple case. We have two files from Linux’s syslog daemon. One is the messages file and the other is the crontab log.

Here are four lines from the messages file:

And here are five lines from cron:

When we’re only dealing with ten lines of logs, it’s easy to see where the merge belongs. The five lines in the cron log belong between the first and second lines of the messages log.

But with a bigger dataset, we need a tool that can merge these two files on the date and the time. The good news is that Linux has a tool for this already.

Merge Log Files With Sort

The sort command can, as its name implies, sort input. We can stream both log files into sort and give it a hint on how to sort the two logs.

Let’s give it a try.

This creates a new file named merge.log. Here’s what it looks like:

It worked!

Let’s dissect that command.

cat messages.log cron.log |

Cat concatenates files. We used it to send both logs to standard output. In this case, it sent messages.log first and then cron.log.

The pipe | is what it sounds like. It’s a pipe between two programs. It sends the contents of the two files to the next part of the command. As we’ll see below, sort can accept a single filename on the command line. When we want to sort more than one file, we use a pipe to send the files on standard input.

sort –key=2,3 > merge.log

Sort receives the contents of two files and sorts them. Its output goes to the > redirect operator, which creates the new file.

The most important part of this command is –key=2,3. We used this to tell sort to sort its input using two fields and three of the files. For some reason, sort starts counting fields at one instead of zero.

So sort was able to merge the two files using the day of the month and the timestamp.

This is our easy case. These log files both had single line entries, and our dataset was for less than thirty days. So we don’t have to worry about sorting by months.

Let’s look at something that’s a little more complicated.

Merge Log Files With Multiline Entries

Here are a couple of Java application logs that we would like to merge.

Here’s the first:

This log has a lot of whitespace and entries that span multiple lines.

Here’s the other:

This log is more uniform, with entries that only span a single line.

When we merge these two files, we want the multiline log message to remain together. So, sort’s numeric sorting won’t work. We need a tool that’s capable of associating the lines without timestamps with the last line that has one.

Unfortunately, no command line tool does this. We’re going to have to write some code.

A Merging Algorithm

Here’s an algorithm for merging log files that have multiline entries.

First, we need to preprocess the log files.

  1. Scan the log file line by line until we reach the end.
  2. If a line has a timestamp, save it and print the last saved line to a new file.
  3. If a line has no timestamp, append it to the saved line, after replacing the new line with a special character
  4. Continue with step #1.

We could do this in memory, but what happens when we’re dealing with huge log files? We’ll save the preprocessed log entries to disk so that this tool will work on huge log files.

After we perform this on both files, we have a new one that is full of single line entries. We’ll use the sort command to sort it for us, rather than reinventing the wheel. Then, we’ll replace the special characters with new lines, and we have a merged log file.

And we’re done!

Let’s do it.

Merge Log Files With Python

We’ll use python. It’s available on all systems, and it’s easy to write a cross-platform tool that manipulates text files. I wrote the code for this article with version 2.7.14. You can find the entire script here on Github.

First, we need to process our input files.

We’ll start by processing command line arguments. This script accepts two:

  • -f is a comma-separated list of input files
  • -o is the name of the file to write the output to

Argparse gives us a list from the arguments passed to -f and opens the output file for us, as we’ll see below.

Python Regular Expressions

Then we’ll create a regular expression. Let’s take a close look at it since this is what you’ll need to change if your logs are formatted differently.

Here’s the whole expression:


The expression starts with a caret ^. This means the beginning of a line.

But then we have this: [^ ] with some characters in the middle. Square brackets with a caret at the beginning mean not.

So the expression means “if this is not at the beginning of the line.”

The pattern we’re matching is inside the brackets.


Each 0–9 corresponds to a numeral. Each \- is a dash. So it could be read like this: NNNN-NN-NN. It’s a pattern for the date we see at the beginning of each log entry.

So in English, the expression means “if the line does not begin with a date.”

If you need to process logs with a different format, you’ll need to change this. There’s a guide to python regular expressions here.

Sorting the Results

Now, we’ll start the real work.

  1. Open a temporary file.
  2. Open the first log file.
  3. Join lines with no timestamp to their predecessors, as described above.
  4. Repeat this for each file passed on the command line.

For the third step, we’ll chop the newline ‘\n’ from the end of the last line we saved. Then we’ll add an SOH (‘\1’) character and concatenate the lines. (I could’ve done this in one line, but I spelled it out to make it clear.)

We’re replacing newlines ‘\n’ with the SOH character instead of NULLs (‘\0’) because nulls would confuse python’s string processing libraries and we’d lose data.

Finally, the result of this code is a file named tmp.log that contains the log files preprocessed to be one line per entry.

Let’s finish the job.

Check_output executes an external command and captures the output.

So we’ll use it to run sort on our temporary file and return the results to us as a string. Then, we’ll remove the temporary file.

We wouldn’t want to capture the result in memory with a large file, but to keep this post short, I cheated. An alternative is to send the output of sort to a file with the -o option and then open that file and remove the special characters.

Next, we’ll split the output on the new lines into an array. Then we’ll process that array and undo the special characters. We’ll write each line to the file opened for us by argparse.

We’re done!

Let’s run this script on two files:

./mergelogs.py -f foo.log bar.log -o output.log

And we’ll see this.

Log Files, Merged

In this tutorial, we covered how to merge log files, looking at a straightforward case and then a more complicated situation. The code for this is available on Github, and you’re free to download and modify it for your individual needs.

Getting Started with Python and Feature Flags

Python is a fun language, and I’ve been trying to use it every chance I have. This post was one of those chance. I wrote on guide on using Rollout’s feature flags with Python. You can find the original post here.

You’re doing it right. You’ve set up an array of microservices that offer REST APIs to support an enterprise application. Your architecture is comprised of loosely coupled services that have enabled your team to roll out updates quickly in response to new feature requests and bugs. But when it comes time to make a change, you still find yourself struggling with dependencies. While it’s possible to version your APIs, you want something more granular. A new API still requires a release of both a new service and a new client application.

Wouldn’t it be nice to coordinate a change between client and microservice without rolling out new code?

It is possible. Feature toggles (also known as feature flags) give you that ability and more. They provide a way to control new behavior in an application by enabling or disabling it without deploying a different version. You can install these toggles in services and clients. For example with REST services, you can toggle new behavior for a subset of users or only enable it after deploying a new client application.

So we add a new parameter to our configuration file or the command line, default it to “off,” and flip it “on” when the new client is deployed, right?

No. That’s not a sustainable solution. It’s a hack. Updating a configuration file isn’t necessarily easier than deploying a new configuration, nor should it be. In many systems, a configuration change is a new release. And what happens when the migration to the new feature is done? Does the feature stay in the configuration file? How big will your configuration file get after a few years? Is it possible it gets turned on by mistake someday?

There’s a better way. There’s feature flag management. Instead of using configuration variables that evolve into technical debt, you manage feature toggles from a feature flag management platform. You can integrate them into a strategy for improving your code, enhancing your ability to support your application, and making your customers happier. With a central management platform like Rollout, you can group flags and coordinate a new feature between client and service, based on a variety of factors like application version and client platform.

We’re going to add a feature toggle to a REST service written in Python. We’ll start with a simple flag that’s managed in configuration and then migrate it to Rollout as part of a secure feature flag management system.

This tutorial assumes familiarity with basic Python and a little bit of Flask. You’ll need to have Python 2.x installed on your system, along with PIP.

Setup and a Basic Web Server

First, you’ll set up a Python virtual environment to run the microservice.

If you don’t have virtualenv installed yet, you can install it with PIP.

Next, create a directory and run virtualenv inside it. Then use the virtual environment’s Python to install Flask.

Now you have a virtual environment installed with Flask. We’ll be doing all of our development here. You can use any editor or IDE you wish for the following examples. I’ll just show code snippets and the output of most commands.

First, let’s create a simple web server, so we’re sure everything is in working order.

So, create a file name webserver.py and add this code:

We created a Flask application and set up a route for the root path. When a browser requests the root document, the server will return a greeting in plain text.

Next, let’s make it executable, so we can run the script.

Finally, it’s time to run it.

python feature flag guide

Now point your web browser at localhost and port 5000.

pything feature flag guide hello rollout

We have a simple web server to work with. Next, we’ll add a REST endpoint and a feature flag.

A Python Feature Toggle

Now, let’s turn this into a REST service and add a simple feature toggle.

First, we’ll define a document that represents a normal day. Our service will return this document in response to a REST request. Next, change the one and only route to return that document when it receives a GET request with no parameters. Finally, edit the URL path to look more like a REST application.

So, we’ve established calendar/api/v1.0/whatistoday as our endpoint. Let’s hit it from the browser.

Rerun app.py.

python feature flag guide
Then point your browser at the new URL so we can see what our REST response looks like.

python feature flag guideWe have a basic REST service! Now, let’s add a feature toggle.

Not every day is just another day. We need a feature for holidays that we can flip when we want to return a different response to our GET request.

First, you’ll need to create a configuration file.

Create a file name calendar.properties with a single section named calendar and a single property named holiday. Start with it set to true.

Next, add the code to read it to app.py.

Add ConfigParser to the imports.

And use RawConfigParser to process the file.

So, we have a boolean that indicates whether or not it is a holiday.

Now let’s use modify our route, so it uses the configuration property to decide what document to return.

We have two different days defined, and the rest service will return one of the other depending on the configuration setting.

So, start app.py and refresh your browser.

python feature flag guideSince holiday is set to True, we see the holiday JSON object.

Next, stop app.py and edit the configuration file to set holiday to False.

Start the service, and refresh the browser again.

python feature flag guide

Since we flipped value for holiday to false, we see the message for a normal day again.

We’ve added our first feature flag. The value of holiday in the properties file controls our application’s behavior. We can return the desired JSON object by modifying the configuration and without deploying new code. But, we still need to manage the configuration file and restart the application after we change it.

Python Feature Flag Management

A properties file is not a feature flag management system. It requires modifying a configuration file in production, which is an accident waiting to happen. If we want to avoid editing live configurations, we have to version and distribute configuration files like code so we can track changes.

So let’s look at a better way to manage Python feature toggles with Rollout.

Getting Started With Rollout

First, you’ll need to create a free Rollout account here.

Once that’s done, sign in to your account and create a new application.

python feature flag guide
Be sure to select Python, as shown above.

Next, you’ll see instructions for adding Rollout to your application. Leave this dialog box open while you set up your environment so that you can return to it. You’ll want to use it later to finish setting up your application.

Now you need to add Rox to the virtual environment you’ve been using. Execute rollout/pip install rox from the command line.

python feature flag guide install rox

Pip will generate a lot of output.

Initialize the API

Next, we need to initialize the SDK with the application key shown above. First, add the import statement import rox.server.rox_server to the top of the file. Then add the call to Rox.setup() with your application key.

We’re going to run this once to initialize Rollout, so the rest of the application can stay the same for now.

Click Next on the installation dialog.

python feature flag build and run
Rollout is waiting for the application to initialize. Run app.py.

python feature flag guide success

The application will bring up the web server, but we’re only interested in initializing Rox. When you see the that the server is ready for requests, check and make sure you see the Success message above.

Creating a Python Feature Toggle

Click Go To App on the success dialog in the Rollout dashboard if you haven’t already. On the left-hand side of the page, there is a Flags menu item. It’s not enabled yet, because you haven’t created any flags.

So you need to add a feature toggle to your application. This is a two-step process. First,  define the toggle in your application code. Then run the application, and the new flag is registered in the Rollout dashboard.

We’re going to add the feature toggle code in the main source file to keep things simple. In a production application, you’d break things down into different files for each class.

Feature flags are kept in RoxContainers. Let’s add one to the application.

First, import rox_flag into the application.

Then, create a container class with a single member. Near the top of the file.

This class contains a single member named isHoliday. A RoxFlag holds a feature toggle. You’ll see how to use it in a moment.

Create an instance of the container, and then once the container is created, register it with the Rox API. So right before the call to Rox.setup(), call register with the container. Register accepts a name with it. We’ll call this one Flags.

Now, run the application and let it finish initializing. Just as before, stop it when it starts waiting for requests.

Return to the Rollout dashboard, and click on the Flags menu.

python feature flag guide

The flag has been registered with Rollout. Since we registered the flag in a container named Flags, its name in the dashboard is Flags.isHoliday. Naming containers provides a mechanism for organizing flags (and other variables managed by Rox) in a large application.

Using a Python Feature Toggle

Now we need to wire the toggle up so we can use it to control our application’s behavior.

A RoxFlag has an is_enabled() method that we call to see if the feature is toggled true or false. So, let’s integrate the flag into our code.

Here’s the entire application after adding the code to use the toggle:

Inside the application route, we replaced the boolean we loaded from the configuration file with isHoliday.is_enabled().

Creating an Experiment

We manage flags by adding them to experiments. An experiment is a scheme for controlling flags (and other variables) in production.

Click on Production in the left-hand side menu and then click Experiments. This will bring up a screen with a Create Experiment button. Click that and then fill out the new experiment window with a name.

Python Feature Flag Guide

And we see a console for setting flags to true, false, or split. Several criteria can set the flag’s value. For this tutorial, we’re going to stick with setting the flag as true or false for all users.

The flag defaults to false or disabled. Let’s run the application and see it in action.

Run app.py.

python feature flag

Next, refresh your web browser.

python feature flag

We see the record for a normal day.

Head back to the experiment and set the flag to true for all users.

Next, restart the Python script.

Then refresh your browser again.

python feature flag

It worked! We can manage our feature toggle from the dashboard.

Refreshing the Flag

The REST service only retrieves isHoliday’s value on startup. If we want to toggle the flag, we still need to restart our application. We’d rather be able to toggle the flag in real-time. Let’s fix that.

We can refresh Rox API toggles with Rox.fetch(). We can call this anytime in our application to get the latest state of our flags. But, this is a Flask application, and Flask wants to control the main thread. We need to set refreshing the feature toggle values up as a background task.

It would also be nice to know if the flags have changed each time we run fetch. So, let’s make two last code updates.

First, let’s pass some configuration options to Rox.setup().

We configure the Rox API’s behavior with the RoxOptions class. We’re going to install a configuration fetched handler. This is a callback that Rox will call when the latest state of our flags is fetched.

We created an instance of the class and passed in a lambda to run when the configuration is fetched. We’ll print a message stating that the fetch completed and whether or not there were any changes.

If you run the application now, you’ll see that is called once, on application startup.

Next, we need to install a function that will periodically run and fetch the flag state.

Since Flask wants to control the application threads, installing a thread before it starts or trying to run in another thread before transfer control to it can cause problems. Our best option is to create a Flask job.

Add this code to the application before you execute app.run. 

This code installs a thread that will run Rox.fetch() every three seconds. This thread won’t interfere with Flask’s request handler.

Now, start the application again, and make a few requests. Then head back to the Rollout dashboard, change the flag, and make more requests. You’ll see that the service returns a different result depending on how you set Flags.isHoliday.

python feature flag

The REST service is picking up the requests and changing its behavior. You can toggle your feature flag in real-time.

Start Managing Your Feature Flags Today

First, we built a small REST service using Python and Flask. Then ee added a basic feature flag and then upgraded the application to a managed feature toggle with Rollout. We finished by integrating reading toggles with Flask’s main event loop.

This is only the tip of the iceberg! Rollout can manage configuration flags that hold more than an enabled or disabled state. Experiments can distribute flag values over different users based on values such as application version and device.

Sign up for a Rollout trial today and take control of your feature flags and application strategy.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑