08 Aug 2017

Flexible Infrastructure with Continuous Integration and Feature Flagging

flexible infrastructure

I’m incredibly excited to be LaunchDarkly’s first solutions engineer. During my first week I got to learn about some of the clever ways we do feature management. Not only do we use feature flags to control the release of fixes and new features, but we also use them to manage the health of our infrastructure in production. I’ve been a part of a number of teams, and I’ve never seen a more advanced development pipeline.

Normally, dealing with issues in production can be a frightening and time-consuming experience, but adopting a mature continuous delivery pipeline can allow you to react faster and be proactive. Continuously integrating and deploying makes getting fixes into your production code a trivial task, but using feature flagging takes it to the next level and lets you put fixes in place for potential future pain points that you can easily enable without having to do another deploy.

One common problem is handling extreme server load. This is managed easily with LaunchDarkly. Imagine you have a server that is pulling time-sensitive jobs from a queue, but the queue fills faster than the server can handle it, and causes all jobs to fail. In situations like these it would be better to at least get some of the jobs done, instead of none of them. This is concept is known as “bend-don’t-break”.

I built a proof of concept using Python and rabbitMQ which demonstrates how you could use LaunchDarkly’s dashboard to control what percentage of jobs get done, and the rest get thrown away. If the worker takes too long to get to the job, the job fails. As you see the queue grow you can manage it easily with feature flags.

It consists of two scripts, taskQueuer and taskWorker. The taskQueuer adds imaginary time-sensitive jobs to the queue; the rate is configurable using feature flags.

The taskWorker removes one job from the queue and processes it. One job takes one second. If tasks are queued faster than the worker can process it, the queue fills up and the worker will begin failing. To protect against this, you can use the “skip rate” feature flag to allow the worker to drop a certain percentage of jobs on the floor.

The concept of using LaunchDarkly as a control panel to manage the operation of your app is really cool and opens up a world of possibilities beyond simply percentage rollouts and canary releases. If you have an interesting implementation, get in touch with us at hello@launchdarkly.com and maybe we’ll feature it!

More about tough devops: https://insights.sei.cmu.edu/devops/2015/04/build-devops-tough.html
More about using Python with rabbitMQ: https://www.rabbitmq.com/tutorials/tutorial-one-python.html
More about LaunchDarkly’s stack: https://stackshare.io/launchdarkly/how-launchdarkly-serves-over-4-billion-feature-flags-daily

07 Aug 2017

Growing at LaunchDarkly: An Intern’s Perspective

When I first visited LaunchDarkly back in March, I knew there was no place I’d rather be. Coming straight out of college, moving fast (and breaking some things) had become my mantra. What I soon realized was that a high-velocity release cycle doesn’t have to mean that code quality should be sacrificed. Who knew that gateing your code behind feature toggles would basically annihilate the risk of releasing faulty features to your users? I certainly did not.

Photo via Tumbler

Working to refine the Customer Success process at LaunchDarkly has taught me many things. Ranging from working with the development team to fight fires, to assisting in product design to meet customer needs, being a Dark Launcher has created a great interdisciplinary experience. Customer Success has allowed me to build a web of knowledge on how a SaaS startup works and which requirements need to be satisfied for success on all fronts.

If I had to choose the best part of being at LaunchDarkly, it would be the people here and the atmosphere they create. This summer has been a really exciting time to be a part of this team. I’ve had the chance to watch the team almost double in size. This has meant that we have had may conversations about culture and the type of company that we each want to be a part of. One outcome of these conversations was the addition of  a “Buddy Lunch” program, an initiative which aims to introduce peers to each other on a more personal level and enjoy some awesome food!

I’m happy to announce that I’m transitioning to a full-time support role here at LaunchDarkly! It feels like I’m the outcome of a feature experiment that went really well, and now I’m excited to go into production full-time.

27 Jul 2017

To Be Continuous: Celebrating Failure, Founder Guilt, Serial Entrepreneurs, Startup Myths, The Everything Else Person

In the latest episode of To Be Continuous, Edith and Paul discuss a medley of start-up pertinent topics. Paul wonders whether the pendulum has swung too far the other way, with too many startups now glorifying failure.

They also examine ways of coping with founder guilt and dispel some common myths about life in a startup. Finally, they examine the invaluable role of the “Everything Else” person in start-ups. This is episode #35 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Celebrating Failure, Founder Guilt, Serial Entrepreneurs, Startup Myths, The Everything Else Person” »

25 Jul 2017

Launched: LaunchDarkly SOC 2 Certification

Providing an always-on, highly secure feature management service is core to the LaunchDarkly platform. From the beginning we have designed and built our infrastructure and practices with security and availability as a priority.

Today, we are announcing the next level of this commitment to Enterprise readiness and stability and are pleased to have achieved SOC 2 Type 1 certification.

Here are a few examples of what you can read about in the report:

  • LaunchDarkly security policies
  • LaunchDarkly logical and physical access controls
  • LaunchDarkly change management process
  • LaunchDarkly data backup and disaster recovery strategies
  • LaunchDarkly system monitoring, alerts and alarms

Protecting the data and privacy of our customers is a non negotiable aspect of what we do. Our SOC 2 certification provides you with an additional assurance that we have all the right controls in place to protect your data and ensure the availability of our service and your features.

To request a copy of LaunchDarkly SOC 2 report, please email trust@launchdarkly.com.

 

 

 

 

 

20 Jul 2017

Feature Toggling On, Three Years In

Wow, three years goes by in a blink of an eye. Three years ago John (LaunchDarkly co-founder) and I both started working full time on LaunchDarkly. We had an idea that we could draw on both of our experiences in software development to help make better software. Funnily, John and I had wanted to start a company together for a long time, but thought we didn’t know enough about any field. So, in the meantime, we’d both continued to work in software for decades. As it turned out, we know a lot about software development lifecycle and managing features effectively.

Now we have customers all over the world (literally) who use our software to eliminate risk and for feature management. One of the favorite parts of my job is to visit customers – I love hearing how they’re using LaunchDarkly and how we can help them manage features. Just in the last four weeks I’ve visited customers in Singapore and Switzerland. And amazing to me, their use cases were very similar – moving away from long lived branches, getting code out more quickly. A CTO in Hong Kong made a brilliant analogy of feature toggling to “lean manufacturing”. The idea of lean came from Toyota; if you circulate through your inventory more quickly, you can be more productive. The same can be applied to code – the quicker you can get it out to the real world, the more effective you can be in validating your ideas and honing its quality. I’m proud that not only do customers love us with a high NPS, but we were also recognized by Gartner this year as a Cool Vendor in DevOps.

Also, the company itself has grown. We have our own office now in Oakland! It’s in a beautiful Art Deco tower, and we are still able to enjoy eating lunch together every day. One of the happiest things the team did lately was rotate all the lunch tables so we had one long table (Hogwarts style). The team didn’t want anyone to have to sit alone if there was no room at a table. Adam Zimman, our VP Product, summed up why he liked working here with “I feel like I can bring my whole self to work; and I’d like to build a culture where everyone feels that way.”

What’s next for LaunchDarkly? We’ve got more functionality coming to help you with effective feature management. We’re hiring! And we’ll also be on the road more – we’ll be at NDC Sydney and Atlassian Summit. I recently met Jeff Lawson from Twilio – he mentioned to me he tries to meet with three customers a week, a worthy goal. My goal for the next year is to meet with at least two customers a week. Come by, say “hi!” We’d love to hear how you’re doing feature management.

17 Jul 2017

To Be Continuous: Common Developer Monetization Mistakes

In the latest episode of To Be Continuous, Edith and Paul examine how monetization approaches vary depending on the developer market you’re in.

They discuss how developer markets can be divided into four spaces and examine the companies operating in each space. They also consider the pitfalls of startups that push their product in too many directions and consider how to go about evaluating the threat of Amazon cloning your service. This is episode #34 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Common Developer Monetization Mistakes” »