The terms serverless, lambda and “#noOps” have been circulating. At a cocktail party, it will cause business owners to find that now is the perfect time to go freshen up their drink.

Don’t.

Serverless architecture is as important to businesses as electricity was to the Industrial Revolution.

Serverless architecture is an infrastructure breakthrough in allowing developers to focus on business value, instead of operations. Just as we plug a toaster, iPhone or refrigerator into an electrical outlet, secure in the knowledge that we don’t have to do anything more to get what we want, so will serverless architecture power business applications. Just as the evolution from watermills to steam power to electricity powered the Industrial Revolution, so will the evolution from dedicated servers to cloud computing to serverless power the software revolution.

Originally “mills” were literally watermills, located on water ways so that water wheels could provide power. There were gristmils (to grind corn or wheat), sawmills (to cut logs into boards), paper mills (to make paper).

Before the invention of steam or coal power, humans used nature’s potential energy to drive more power than a single person could muster. Of course, the consequence of using water mills was that the mills were literally co-located with the machinery they drove. It wasn’t possible to have a water wheel power a gristmill 10 miles from the banks of the river which powered it. Your mill was by definition vertically integrated – and if there was a drought or insufficient water flow, no milling could occur.

Server farms are today’s water mills

The computer analogy of the water mill is to the first server farms. If you were a software business, you needed a data center. You needed a data center with machines that were labeled with your businesses name, and you needed people who could run them. If you had a new project, you needed to build a new server to go along with the project. Depending on how much influence you had in the organization, this could take a long time, as even with much influence, do you think it’s easy to just get a new water wheel up and running? No. It’s not easy. You had to find the budget for a server, buy the server, get the server up and running.

When steam and coal power were invented and commercialized, suddenly manufacturing throughput exploded. Mills no longer had to be at the banks of rivers, and could be anywhere, and grow much larger. Ford built the huge Rouge plant in Illinois, capable of building hundreds of autos a day. A similar step happened when AWS started selling  “Web Services”. Instead of the old days of having to provision a server at a colocation facility, AWS now does it for you. Want another server? No problem! The old days of opening a ticket, waiting for your ticket to be addressed, and then installing an application are gone.

“Life as the engineering owner has gotten easier now that someone else runs the hardware for me,” says Andy Denmark, CTO Chairish and formerly of OpsCode and TripIt. “I don’t need to wait, and what used to take a full time staff member and months of work is now less money and much quicker.”

The final wave of the industrial revolution was electricity. Ford ran his own power plant to build his cars. Now, factories instead of building a power plant and being constrained by their own power supply, buy power from potentially thousands of miles away.

Serverless is the natural progression

Serverless is the same step – it allows developers to plug APIs and not worry about which server or where code runs. With Amazon’s Lambda Instead of having to worry about an AWS instance  — spinning up, spinning down — just plug functionality into the grid. What server it goes to isn’t your concern.

“AWS Lambda’s been great for Wordnik.t helps us, as a small nonprofit, be extremely flexible and responsive,” says Erin McKean, CEO of Wordnik.t. “For instance, we’ve been able to prototype robust new APIs for edtech clients with minimal cost and developer time. We don’t have to spin up & pay for a 24/7 server for an API that’s just called a few hundred times for testing.”

What is the business impact? In the short term, the ability to do more, better, more quickly, by completely separating software from hardware by delegating running servers to someone else. If this seems threatening or disempowering, think about whether your business’s core competency is running servers, or building software. Do you want to do more with less overhead? Or do you want to run hardware? Of course, there will still be a very few businesses where it makes sense for them to maintain their own servers. And legacy software can’t move to serverless architecture overnight.

Serverless is the right step to make business value for applications as easy as plugging a phone into the wall.

The post Is serverless architecture the electricity of software? appeared first on ReadWrite.

Guest author Edith Harbaugh is the CEO and cofounder of LaunchDarkly, a service that helps software teams launch, measure, and control their features.

The DevOps revolution has focused on automation and smoothing the process of getting code from developer box to production. Essential tools like Puppet, Ansible, and Chef enable builds in minutes where it used to take hours. 

DevOps 1.0 has made it easier to maintain the traditional waterfall pattern of developer box, QA, staging, and production. However, even the notion of a build is increasingly antiquated. If developers can check code in every day or every hour, the idea of a build is antiquated, as are separate systems for QA, staging, and production. Maintaining these separate systems is a legacy of waterfall development, and will be subsumed by true agile deployment and what I am calling “DevOps 2.0.”

Hanging Separately

When software development first began, code changes were immediately checked into the production environment. There were many issues with this. If something broke, it was immediately broken for everyone. If you had multiple developers (or multiple teams of multiple developers) the chance of something breaking climbed exponentially. Though it was time-efficient to move directly into production, the price was paid with quality and stability. 

A best practice arose of “cascading” environments and moving releases though a release cycle of separate servers for development, test, staging, and production. These separate servers tried to map into the roles in a good software organization. Product managers and user experience design the product, making requirements and interface. Developers code the requirements. Quality assurance verifies that the code does its job and doesn’t break any old functions.

Depending on the size of the organization, each role could have multiple people or teams, or just one person doing all roles. But even then, the idea of separation ruled.

Cascading release servers increased quality and stability of code, but at the expense of time. Developers would code on their own local boxes, checking into a master source-control system. When enough changes were made, a build would be cut and put on a quality-assurance Server. Quality-assurance engineers would verify the release on QA, and document any issues for developers with old code or new. The developers would address the issues, then push a new build to QA. 

When QA had verified the build to satisfaction, the build would then be put on staging. Staging was intended to be as close to production as possible, in terms of actual user data. On staging, product managers might give a final check of their features, and performance engineers might run load tests.

There are four key issues with this workflow:

Time

Even super-quick deployments take 5–15 minutes. If an issue is found in production, it can take hours to propagate a fix. The fix must first be verified on QA, and all regression tests done. Repeat on staging, and then push to production.

Inability To Keep Systems In Sync

From my time at Epicentric, I have a patent on packaging up components to push through different systems. Having a separate QA server, staging server, and production server means maintaining three separate systems. Usually an attempt is made to have staging and production have as close as possible the same data set, while QA is a free for all. 

In practice, it makes bugs sometimes very difficult to replicate. Many times a bug can’t be verified on QA as the data set is different. In addition, it’s very easy to get confused.

Expense

Simulating production loads on staging can be extremely expensive, with bills of $3,000–$30,000 not uncommon.

Confusion

This is always the biggest risk. It’s a pain to get internal users to use staging as a real system, knowing that their data can always be overridden or forgotten. At TripIt, I’d put trips into staging, knowing that I’d have to recreate my real trips on production. At PlantSense, we ran a separate beta server, and users would always accidentally go to www.easybloom.com rather than beta.easybloom.com, no matter how many times we asked beta users to use a bookmark .This caused confusion and dissatisfaction—beta users would report “missing data” which turned out to be them accessing the www machine, instead of beta where their data was.

A Flag Of Hope

So how do you push directly from development to production?

The answer is feature flags, sometimes known as feature toggles. These are bits of code written into your application that let you turn features on or off at a moment’s notice for specific segments of your user base.

A feature flag can encapsulate a given change. You then grant access to the people who need it. The same flow from QA to staging to production can happen—all on the same server. You can use it to test new code with just internal users; a small set of beta users; or a cohort of live users. Etsy’s Feature API on GitHub has some interesting examples of how feature flagging can be used.

Feature flagging has the potential to save time and money, increase customer satisfaction, and increase stability and quality. Facebook is well-known for its use of feature flagging, as are many other large tech companies.

Here’s what DevOps 2.0 with feature flagging looks like. A developer makes a change, and tests it on their local machine. She then pushes the change to production, wrapped with a feature flag. The feature is off for everyone. QA verifies the feature on production. The product manager verifies that the feature works as expected. Performance can throttle up and down who has access to the feature. There’s no need to replicate load—the load on the feature is the real load. 

It’s even easy to give access to external users like early beta customers, journalists, and industry analysts. Just grant the access to the feature, directly on production. 

According to Douglas Squirrel, consulting CTO, the secret to releasing directly to production is “to slice features into tiny, user-ready, deployable pieces—and of course you will want to control access to those pieces with feature flags.”

The advantages of pushing directly to production are very clear. Consumers get direct access to features, without the time lag of waiting for them to move through multiple different environments. A huge benefit to an engineering organization is a reduction in the burden and expense of maintaining separate datasets for QA, staging, and production. The tedium wasted in verifying issues in different environments disappears, as well as the time spent keeping them in sync. 

“In the promised land, every developer habitually releases finished code to production at least once daily—and when you get there, there are unexpected benefits to code quality and engineering motivation, as well as the faster user feedback you were probably expecting,” says Squirrel.

“QA acts as a gateway to ensure we tested our features before releasing them to customers, however gateways introduce delays,” says Sam Hatoum, founder of Xolv.io. “With feature flags, we’re able to deploy features to our production environment but hide them from our customers until we are ready. And when we are mostly ready, we can use our users that opted-in to our beta program to helps us with our testing. So by removing our QA environment, we actually increased our ability to increase the quality of our features while benefiting from a speed increase.” 

Better software, faster releases, happier engineers and customers—are you ready for DevOps 2.0?

Photo by Bob Mical

The post Staging Servers Must Die appeared first on ReadWrite.

Guest author Edith Harbaugh is CEO and cofounder of LaunchDarkly, a firm that specializes in “dark launches” or “canary deployment” for companies, so they can deliver features to some users and gauge their reaction before rolling them out to everyone. 

Today, the smartest companies are releasing software thousands of times a day in an approach called “continuous delivery,” a software-development practice of continuously releasing functionality in small chunks.

See also: Open Source: Billions Upon Billions Of Free

When I first started in the software industry in the 1990s, Microsoft was on a five-year release cycle, SAP three years, and Salesforce was just beginning to get traction. I worked at a Java groundbreaker called Epicentric, whose one-year release cycles were considered “blazing fast.” We even had big “release parties” to celebrate them. Now yearly releases are considered quaint. Now my own company, LaunchDarkly, releases “even on Friday afternoon”—traditionally a no fly zone. 

What’s fueling the spread of continuous delivery is supporting technologies like SaaS, Continuous Integration, as well as business needs like user expectations, lean startups, and most interestingly, employee satisfaction.

User Expectations

It used to be enough to release a new version of Windows every four years. Then companies like Facebook set the bar high with software that continually evolves.

The Facebook of 2015 is different than the Facebook of 2010, and the Facebook of 2020 will be even more different. It’s not enough to ship a piece of software and call it “done.” Acompli, a mobile-first mail app, faced an uphill battle in a very crowded field.

“We had to earn every single user, by building a products that was both ‘loved by users and trusted by IT,” said Kevin Henrikson, partner director of engineering at Microsoft and previously co-founder of Acompli.

Mobile has traditionally been tricky territory for continuous delivery, as Apple requires a review of all apps before they push live to customers. Even so, fast-moving companies like Accompli continuously delivered to beta users, who downloaded builds directly. Now a part of Microsoft, Acompli formed the basis for its Outlook app, which is used by billions worldwide.

Lean Startup

Companies want to break value into smaller and smaller chunks to see if they’re delivering value to their customers. It’s devastating for a company to work for two years on a huge release, only to find they’ve completely missed the market.

Smart companies like Yammer deliberately engineer their process to get as fast feedback as possible. “You’ll always have imperfect information, so you have to move quickly with the facts you have, so that you can get more data,” said Kris Gale, VP of engineering at Yammer and now CTO at Clover Health. “You’ll always know more tomorrow, but that doesn’t mean you can be paralyzed today.”

Employee Satisfaction

Engineers want to see their work out in the world. From their perspective, the worst thing is to spend years on a product that never sees the light of day.

Duke Nukem Forever, the followup to the hit game Duke Nukem 3D, took an extraordinary 15 years to develop value. “If an engineer hears in an interview that it’ll take them months to ship something, they don’t want to join the company,” said Will Aldrich, VP of product at SurveyMonkey.

With continuous delivery, engineers can quickly see their hard work go out to real-life users. What has changed the game is the rise of “Software as a Service” (SaaS), which allows users to access functionality over a web browser or mobile app, rather than downloading software application. That makes deployment faster and simpler; if a user has to physically install software, it’s impossible to do true continuous delivery.

All software used to be physically installed on customers’ machines. When I was engineering manager at Vignette, we had a “Supported Platform Matrix” to let us know which databases and application servers our software could be installed on.

It was an ever moving arms race—Oracle would add 10, and we’d have to retest it with BEA WebLogic. Given the complexities, customers generally didn’t want to update more than once a quarter (if even that—some customers clung to Oracle 6 long after even Oracle had shelved it).

Now, with the rise of the cloud, customers no longer feel the pain of installation. They just log into a web browser on their desktops or phone apps, and get the functionality they want.

Continuous Integration

Formerly, developers would code on their local machines, checking code in. When a branch was stable enough, it would be given to Quality Assurance testers to find any issues.

Microsoft had a 2-1 QA to developer ratio, since it was imperative that their software be bulletproof. The back and forth between developers and QA could stretch out, as bugs had to be re-verified on each build.

Now, with continuous integration, unit tests can be run in minutes, to better ensure quality. Companies like Rainforest QA can quickly verify within minutes basic functionality, in real time. If every feature needs a two to one QA to developer ratio with deep thorough manual testing, continuous delivery stretches out.

Continuous delivery is a virtuous circle—by delivering features quicker to end users, both employees and customers are happier.

Lead photo courtesy of Shutterstock

The post The Scoop On Continuous Delivery Of Software Releases appeared first on ReadWrite.

Guest author Edith Harbaugh is the CEO and cofounder of LaunchDarkly, a service that helps software teams launch, measure, and control their features.

As I was going through my fundraising for LaunchDarkly, I was surprised by my friends reactions of “Oh, it’s just like Shark Tank; you pitch four VCs on live TV and they make a snap decision.” 

This isn’t true. Seed fundraising isn’t like Shark Tank. It’s much more like enterprise sales.

Survival Of The Fit

Fundraising is about finding a good fit between a company that wants money to grow faster and investors who want to put their money to work with a high return. Enterprise sales is similar—a company is investing in a vendor that will help them achieve high returns for their own business. 

In both cases, there’s a funnel with leads, a champion, a sales process, and a close.

Below is the sales process I used to raise raising $2.6 million, with bonus help from ’90s classic movie Glengarry Glen Ross. 

Hollywood mythology has the CEO drive down to Sand Hill Road, pitch a partner meeting, and walk out with a check for millions. Actually, the partner meeting is the very last step in the process. 

You start out with all your leads—VCs you think might be interested in buying what you’re selling. But wait, I’m not selling anything! I hear you thinking. Oh, but you are! VCs are buying a chunk of your company in the hopes that you will return their investment by 10x or more. Not every buyer persona matches what you’re selling; you are looking for a VC who understands your market and your vision, and buys into the possibility that you will make them look prescient and rich.

Qualifying Leads

“The leads aren’t weak—you’re weak.”

Pro tip: Know your target market and look for VCs who know your market well. My screen was having investors with experience working in software development.

Make a lead list of everyone you know who fits your ideal lead profile. Define your target market for leads—investors who have a thesis that matches your space and its size. AngelList, CrunchBase and funds’ own websites are very helpful for knowing what investors invest in. For example, if they usually invest in hardware router makers that need a Series D—a big-dollar, late-stage investment—they’re unlikely to invest in your seed-stage home-decorating consumer app. 

Next, make your email pitch with a short blurb of who you are, what you’re doing, and why it’s interesting. The goal of the email pitch is not to have someone drop you a check (only a Sith Lord does that), but to get a meeting with the investor.

Once you’re in the pitch meeting, it’s a two-way street. The investor is assessing whether you have a quality pitch, team, interesting market, and product demo. At the seed stage, the VCs are looking for promise and something that excites them personally. 

As the CEO, you are looking for the right fit to take your company forward. Mike Beebe, a Jedi fundraiser, told me, “You will get the money—you’re assessing if this is the person you want to get money from.” 

I had a pitch meeting where the partner had never heard of Stack Overflow. My own product is a developer tool that helps with getting features to real users faster, and the partner hadn’t heard of one of the most popular developer sites. Not a fit.

Another said they loved me and my story personally, but didn’t understand B2B and would invest if I was doing a B2C company.

The Art Of The Follow-Up

“A guy don’t walk on the lot lest he want to buy.”

Pro tip: Always ask. Always. You don’t know if someone is a yes unless you ask.

The first pitch meeting went well, there’s mutual interest, now what? 

Now comes the follow-up. Tom Drummond, Heavybit managing director, told me that “VCs take 20–30 meetings a week and have hundreds of emails. You need to force your way to be top of mind. Email them, follow up.” 

Once I knew it wasn’t a negative signal to follow up, I used TalentBin founder Peter Kazanjy’s advice:“Touch a lead six times before they’re cold.” After the pitch meeting, send a follow-up. Mine reiterated key points, expanded on anything I felt I hadn’t covered well, and included a customer case study. I asked for next steps. Sometimes the response was “We don’t want to continue.” Sometimes it was “Here’s what we need to move forward,” but at least I knew.

Dave McClure, founding partner at 500 Startups, only invested after I followed up. I’ve known Dave since 2008, when I worked at an Internet of Things startup. He said, “If you ever start a company, I’d invest.” My response was, “I don’t even have an idea, much less a company.” But he said, “The person is more important than the idea.”

When I exhibited at WebSummit Dublin in 2014, I tweeted him to come by the LaunchDarkly booth. He came by, dropped a card, and jetted off. I was disappointed—now I had a company, shouldn’t he have offered to invest? Then I reframed it. He’d taken the time to come see me, and I hadn’t made the ask. 

I emailed him, “Are you ready to make your bet on me?” He responded instantly, saying yes, he was interested, and he’d assumed I wasn’t fundraising because I hadn’t asked him.

Do Due Diligence

“Always be closing.”

Pro tip: Ask a VC to walk you through their due-diligence process. If the VC can’t answer, this is a huge red flag. If they ask for 50 different documents including SEC filings and you’re raising seed, it’s not a good match. If they start to ask for things not in the original plan, ask them why. Usually, it’s cold feet.

Due diligence is often the most confusing phase for entrepreneurs.. As VCs are parting with a significant amount of money, they want to vet you. Angels who are investing $10,000–$50,000 can go on gut, but the more money is at stake, the more vetting will take place.

Every investor has an ever-amorphous idea of what due diligence they need to feel comfortable with you. Some will want to talk to your customers, some will want you to talk to their portfolio companies to see what they think, some will want you to talk to industry experts, some will want to talk to all your old bosses, and some will want to see five years of financial statements, board meeting notes, and your seven-year business plan. Match the amount of vetting with the size of investment, and push back on unusual requests.

If a VC asks you to meet with someone before they’ve invested, treat these meetings as what they are—sales calls. The investor will not invest until due diligence is complete, so do not blow these meetings off or treat them casually. They are not a time to let it all hang out and expose the warts of your business. They are steps in a sales process. Impress the due-diligence people as much as you impressed the original VC. Bring your A-game as to why your company is important and valuable. Due diligence can drag out, mislead, give false hope, and be harmful.

I had an investor who wanted to talk to two customers. He missed both meetings because he was late. When he did eventually show up, he wanted to meet with more customers to “feel convinced.” I didn’t want to burn my customers with a flaky VC who would miss meetings. He never did end up investing.

Another startup CEO had six separate meetings with one VC firm. He didn’t meet with other firms, as in his mind, this firm was about to invest. Startup advisor Sean Byrnes gave him a cold dose of reality: “If after that many meetings they haven’t invested, they won’t. They’re using you to educate themselves on the market.” 

To reframe this in enterprise sales terms, if you’re spending all your time on bad leads, you’re not making good leads work.

The Close

 “Coffee is for closers.”

Pro tip: Always know who your champion is. If you don’t know who it is, you are fighting solo, as no one has an incentive to help you.

You’ve made it through your initial pitch meetings, due diligence, and now it’s time for the final hurdle—the partner meeting. Many think this is the first step, but it is actually the last one. This is the meeting where you pitch to the entire partnership. 

The most important person in the pitch meeting isn’t actually you, but your champion. The champion is the partner who heard your pitch and has the reports back from due diligence. They are trying to get the deal done as they think you’re a killer investment that will make them look good. 

Andy McLoughlin, a venture partner at SoftTech VC, says, “If I’m the champion of an investment deal, I’m even more invested than in vendor selection at an enterprise. The companies I invest in are my product.” 

The champions are there to help you. Use them! They want you to look good, as otherwise they get razzed for backing a loser company. Most firms invest in less than half of companies that pitch the partnership, and it’s not expected everyone will be in favor.

Ask the champion what you should show in the partner meeting. Let the VC run interference on objections. Without a champion, meetings are at best neutral and at worst openly hostile.

In sum, fundraising is hard, but it shouldn’t be a mystery. It’s a sales process, so treat it like that. The goal is that both parties should feel like they’ve found a partner who will help them win.

Screenshot via Glengarry Glen Ross

The post Treat Fundraising Like Enterprise Sales (And Glengarry Glen Ross) appeared first on ReadWrite.