In this episode of To Be Continuous, Edith and Paul are joined by Keith Ballinger and Thomas Dohmke from Microsoft. They share their experience of being acquired by Microsoft and discuss the role of DevOps in the continuous delivery process. They then consider the importance of balancing founder convictions of product value and how the world is changing, with necessary market validation activities. Keith also shares his thoughts on why early-stage founders should ignore larger companies for as long as possible, focusing instead on building their business.
This is episode #40 in the To Be Continuous podcast series all about continuous delivery and software development.
In the latest episode of To Be Continuous, Edith and Paul are joined by Martin Woodward from Microsoft and Ed Blankenship from Algorithmia. They discuss the cultural and technological shift that was necessary to transform Microsoft into an open source company. Martin talks about how as the owner of CodePlex, Microsoft’s open source community, he created Microsoft’s Github account. He also shares tricks he used to drive adoption inside Microsoft, such as allowing people to use their personal GitHub accounts, the subsequent challenges that this created and how he overcame them.
This is episode #39 in the To Be Continuous podcast series all about continuous delivery and software development.
In the latest episode of To Be Continuous, Edith and Paul discuss the challenges and benefits of refactoring monolithic applications into microservices. They examine various approaches for creating microservice boundaries and dispel the myth that they should be defined as small as possible.
This is episode #38 in the To Be Continuous podcast series all about continuous delivery and software development.
We all know beta testing is important—not just for understanding your customers’ needs, but also for stability and security. Every time you do a launch you are essentially asking: “Are there bugs? Is there feedback?” Both with the goal of making your product better.
Testing in production will give you the most information about the success of your new functionality. And because feature flags help separate deployment from release, they make such testing safe and easy. When it comes to beta testing, a lot of the top companies tend to adhere to a similar paradigm—test early, test often, and do it in your production environment.
So how do companies have smooth and simple transitions from alpha to beta testing, and then to full rollout? Read on to learn how top companies are approaching their beta testing using deployment tools with feature flags providing links out to more in-depth descriptions.
But before we get started, here’s a quick terminology review. Pete Hodgson refers to this use of feature flags for betas as “permissioning toggles.” Also known as a “canary launch,” this is often random like a percentage rollout. A set group, or “champagne brunch,” releases to internal users or another section or group.
6 Approaches to Product Launching
#1 Facebook is the prime example of dark launching. Their release management has to be impeccable to operate at such massive scale. Their betas are often up to million users or more.
“Although we push to production only once a week, it’s still important to test the code early in real-world settings so that engineers can get quick feedback. We make mobile release candidates available every day for canary users, including 1 million or so Android beta testers.”
#2 Hootsuite gives a typical rollout pattern for its features—starting internally and then slowly exposing to a larger audience.
Push new code then:
– Dark launch to yourself or your team to test
– Launch to the whole Hootsuite organization
– 10% of all users
– Watch graphs
– Simple means of rollback if necessary
#3 Etsy calls feature flags “config flags,” and gives a lot of credit for their process to Flickr.
“Key system-level and business level metrics (like checkout/listing/registration/sign-in rates) are projected on screens in the office and we have a number of internal dashboards that the team uses (we mainly use Ganglia and Graphite). We also have lots of switches and knobs to help us roll features out to percentages of users and ramp them up slowly, or quickly. Features are used and tested by us here at Etsy for some period of time before they are rolled out publicly.”
#4 Beta can also apply to back-end rollouts. Instagram does canary deployments to a subset of servers, using feature flags as a continuous delivery tool. It’s important for continuous delivery to perform these tests, which are key in helping them avoid failed deployments.
#5 Niantic’s Pokemon Go betas are well known and rabidly tracked by its fans. They famously roll out by region—a field test in Japan here, a limited beta in Australia, and then something in New Zealand. Sometimes these betas for features are invite-only. Here’s a write up of how they approached the rollout of the game Ingress.
#6 GoPro released their GoPro Plus product early using feature flags. By breaking the larger release into smaller features with their own testing timelines, they were able to iterate and improve continuously. The video below walks through the technology they used and the timeline from dogfood to a “big bang” marketing announcement.
“At GoPro you can kind of tell we don’t things lightly. We want to do big announcements and we want to come out with great products…we actually had smaller features that would go out, and then go for alpha testing and beta testing along the way. Shortly after March, we actually had most of the applications done from a core feature standpoint, but we kept iterating and improving those core features that we knew we were going to launch with.”
Controlling Your Rollout Like a Boss
Did you notice some trends there? These larger companies are using beta testing to do one of the following:
Testing in production with feature flags
Ability to release early and test small functionalities before a broader release
Internal tests that easily become external canaries
As more companies start to use feature management, these incremental rollouts are not the headaches they once were. Companies can be safer and smarter with how and when they expose features to their end users.
If you want to get started with feature flagging, check out featureflags.io a resource we made for the community to learn best practices.
In the latest episode of To Be Continuous, Edith and Paul are joined by Jeffrey Snover, the inventor of Windows PowerShell. Jeffrey describes the tremendous cultural shift that was needed to shift Microsoft to a continuous delivery model.
Jeffrey recalls how he overcame the cultural challenge by finding the “coalition of the willing” and starting small. Jeffrey also recounts his inspiration behind PowerShell and talks about how today every layer of the technology stack is undergoing a revolution.
This is episode #37 in the To Be Continuous podcast series all about continuous delivery and software development.
You are a new Director of Engineering at an enterprise company. The company has just moved your product to the cloud and is hosting in Microsoft Azure. You come from a tech startup where you ran all of your software in the cloud and focused on building product. So naturally you have just implemented instrumented monitoring with HoneyComb, Kubernetes to manage your containers, and you’re thinking about leveraging serverless architecture.
You moved to this established enterprise company because they are providing technology to the healthcare industry and you are passionate about this space. They want you because you are good.
Now you face a challenge—how can I bring the good things from my past role and pair them with the security standards and compliance in my new role? Well, let’s first think about what the good things from your past role entails. Your previous team:
Deployed 5 times a day
Used feature branching
Feature flag first development
Implemented continuous integration
You realize you used 3rd party software for most of these good things, and had homegrown for others. You decide your first project is to research what software the new team is using, has built, and what software you will need to build and buy.
Security and the cloud.
Now, before we dive in, let’s consider the security standards and compliance you need to think about in your new role:
Where is my data stored?
What data is being sent over to the third party—is it PII?
Where connections are made to third parties?
How can I set different access control?
How it will work when connection fails-redundancy?
Is it HIPAA compliant?
How is all this audited?
Like your new company, many companies are just starting to move key operations to the cloud. This is SCARY. Moving into Azure will allow your company to free up floor space, add more server redundancy, easily scale up and down, only pay for what you use, and focus resources on revenue generating activities— security is still your responsibility. And though these are all great things, you are not a security company.
Now you are tasked with bringing in these good processes, and they include 3rd party software providers. Products in this space are inherent in your development lifecycle and very close to your core application, but you need to ensure they are secure.
As we all know, most software providers in this space are cool tech companies in The Valley, far and isolated from the realities of your secure enterprise world. You look at on-premise options. And you remember that you’re driving change in the Healthcare space, not looking to manage infrastructure. The cloud options require a significant audit that is time consuming. A SaaS provider carries an ongoing risk that requires you store some data on 3rd party servers, which is a non-starter in Healthcare.
Is there a middle ground?
There is one more option many software providers offer: Private SaaS, also known as a managed instance, Dedicated VPC, or private instance. You surmise if they do not have on-prem, private SaaS, or a really really good security team, then it’s not likely their team is accustomed to working on enterprise challenges.
What exactly is a private SaaS offering? This refers to a dedicated single tenant, cloud software where the vendor manages the infrastructure.
Why choose a private instance?
Single Tenant—You will have a dedicated set of infrastructure contained within a VPC. This eliminates the risk of noisy neighbors.
Data Storage—Data can be stored in your AWS account or in an isolated section of the vendor’s AWS account. This allows flexibility, if you are in the EU, vendor could spin up the instance in AWS in the EU.
Residency—If you have a preference on where the instance is located or need to ensure proximity.
Compliance—If you have additional security or compliance regulations, a private instance can be customized to fit your needs.
Change Cadence—If you need to know when the software will be updated, you will have better insight and greater flexibility with a private instance.
Integrations—If you have custom tools, integrations can be built.
You have narrowed down a few software providers for each job you are trying to solve (continuous integration, branching, feature flagging). You understand the value, the costs, and the security implications. You have chosen to stay in the cloud, which makes your infrastructure team happy. You have chosen to use private instances and SaaS where it makes sense, which makes your security team happy. And you have the tools you need to bring the good things into your new role, so you are happy.
Now you can focus on helping your company deliver product faster, eliminate risk in your release process, speed up your product feedback loop, and do it all securely.