Our Story

How enStratus Became

Learn more about how enStratus™ launched the business

In The Beginning

Our team has been in the Software as a Service (SaaS) business since 2003 as Valtira. enStratus started out as a tool we built in 2007 to solve our own challenges deploying our applications into the cloud. The reaction of others and their requests for help led to the creation of enStratus the business.

Here's our story ....

A Little Background

Valtira is a marketing platform that essentially is to the marketing department what Salesforce.com is to the sales department. We have always offered our software as a "cloud-like" service in which we take care of the infrastructure and system support. Unlike Salesforce.com or other typical cloud services, our problem domain had a nasty barrier to entry: people generally used our solution only when they were building a brand new web site. So our $10,000 software product ended up being part of a six figure budget decision and it required a lot of services before the customer was deployed.

We wanted to start making key parts of our infrastructure available on-demand in a way that would integrate well with a company's existing web infrastructure. As a result, in 2007, we created a plan for developing on-demand personalization widgets (which we call SmartSpot) and on-demand landing pages. This way, people could personalize their existing web sites, engage in marketing campaigns powered by custom landing pages, and integrate with all their marketing tools without any IT or development support.

Cool right?

The challenge was that this infrastructure needed to be high-availability (HA). We architected the Valtira platform to operate in a high-availability, clustered environment. But we always made clients with HA needs cover the costs for their infrastructure on their own. This time, we needed to buy an HA infrastructure for ourselves and did not want to invest the six figures necessary.

Looking at Cloud Options

We began researching mechanisms to avoid making the HA investment while still retaining an HA environment. We also had two start-up clients that had the need to move away from single dedicated hosts into HA environments - but they still had start-up budgets. We dismissed Google App Engine and other similar technologies that required you to write to a specific API. After all, we had a mature existing product and did not want to modify or re-write it to support some cloud provider.

Eventually, we stumbled into Amazon Web Services. We began with a small pilot program. To be honest, we thought the promise was way too good to be true. At each point, we expected to run into a "gotcha". We ran into several pseudo-gotchas that would have stopped a less motivated researcher. Among the ones we encountered were:

IP address management

IP addresses are all dynamically assigned, you have no netblock at any level, and (once upon a time) there was no option for static IP address assignment.

We believed we could automate a solution to this issue. We crafted some code in short order and then we were on to the next problem.

The lack of persistent storage

This problem no longer exists thanks to Amazon Elastic Block Storage. Once upon a time, however, there was no Amazon EBS. If you lost an instance for whatever reason, you lost the data. Game over.

If we were a big company with a lot of cash, this issue would have stopped us. It almost did; after all, Valtira is a database-driven application. We created a solution that essentially kept your MySQL slave synced with Amazon S3 (which was good enough for this particular use of the Valtira platform) and realized this solution had the virtue of providing automated disaster recovery.

Security

The Valtira on-demand products do not really store any sensitive data. Once our enterprise clients heard what we were doing in the cloud, however, they started asking about making the move. They began asking a number of security questions about the cloud:

How do you do intrusion detection? How do you manage authentication credentials? How do you VPN back into our backend services? And many more. These problems seemed really hard, but we eventually overcame them as well.

Go or No Go

Eventually, we proved we could operate in the cloud for both our on-demand needs as well as most enterprise customer needs. The question was, did the costs work out?

To have put together an infrastructure to meet our needs, we would have needed to start with an F5 load balancer, two Dell application servers and two Dell database servers. We would have needed to purchase another rack at our hosting provider and purchased additional networking and firewall equipment. Taking this approach would have diverted money from other things in the company.

With the cloud, however, we did all of our prototyping on the cheap Amazon instances and even deployed our initial infrastructure on cheap instances (we would never have put our money into such puny servers for a hosted infrastructure). In short, we can achieve 99.99% availability (assuming Amazon lives up to its 99.95% SLA) for about $360/month.

We made the jump.

Reality in the Cloud

Valtira has been fully operational in the Amazon cloud since May 2008.

We have identified two key learnings:

The cloud is much more cost effective (don't let people's machine vs. machine comparisons fool you!) you need cloud management tools to make the thing work out right

Costs

If you compare the costs of an Amazon EC2 instance against the costs of a comparable piece of physical hardware, the EC2 instance almost always comes out being more expensive. Unfortunately, many of the cost analysis articles you see on the Internet engage in this kind of comparison.

The best way to compare costs is to look at how you would build out one infrastructure versus the other. As noted above, for an HA Valtira on-demand infrastructure, we would have purchased a beefy firewall with beefy servers behind it. You simply don't have the option of trading them in easily without downtime and expense when your needs go up.

In the Amazon environment, however, we started with all of the cheap stuff. It worked well enough well past the point where we had proven the business model. At that point, it was a simple matter of restarting the instances with the beefier machine AMI.

We also don't have to buy a firewall, we can live with a cheap EC2 instance providing software load balancing, and don't have to buy any network equipment.

Support

Cloud governance tools are important because the cloud will eat up many more person-hours in support (and reducing your availability) than traditional infrastructure unless you have software taking care of all that. Thanks to the Amazon web services API, most everything - including disaster recovery, becomes an automated process and ultimately saves you on manual work over a traditional infrastructure.

We ended up building our own cloud management tools because we had enterprise-level needs that we did not see out there on the market. Whether you write your own or use commercial ones, you will need the help of cloud infrastructure management tools. We spun ours off into another company, enStratus - and our world has changed dramatically ...

Learn more by continuing on to our Second Chapter.

Ramping The Business

Learn how we expanded our features, cloud providers, and customers

The Second Chapter

The second chapter for enStratus really begins in late 2008 when we delivered our first windows application in the Amazon cloud. The client was a well-respected marketing agency and the system was a loyalty marketing solution with sensitive, if not super-sensitive, data.

The security architecture we adopted 9 months earlier had been critical in winning that first loyalty project. That in turn led to another loyalty project, this time with more sensitive data, and then another and then an ecommerce project with PCI requirements and then a project with a major player in the financial world. 

Each of these early projects cemented our focus on security and governance - although we didn't yet quite see it in those terms. We had simply built a solution that met the demands of our own enterprise software backgrounds. We designed a security approach that assumed all clouds were hostile and automatically managed credentials and security keys on the basis of a separation of roles - enStratus kept the keys outside the cloud and offered our customers the chance to automatically encrypt any data they put in the cloud.  

At this point in our story (early 2009) the full significance of the market opportunity really started to dawn on the world around us. The cloud hype-cycle was just starting to get into full upswing, the "clouderati" twitter groups were beginning to really fire, and the analysts started long and painful debates on "what is cloud".

Our approach was clearly coming into focus - we didn't do test and dev projects, we didn't do throw-away apps. We did production deployments of apps that mattered and that managed data that people cared about. We also supported each public and private cloud platform as it released API's. To be honest, there weren't many people deploying "serious" apps like that into the public cloud in early 2009. But that's what we did, and many of those who were trying to do that found us and worked with us.

Later in 2009, a guy called us up and said he was working on a project for NASA. We thought that was pretty cool. 

It turns out there are some clever chaps at NASA and they knew exactly what they wanted in terms of governance. They wanted to enhance our user management to allow totally customizable access rights to fully support "least privilege" and they wanted flexible billing controls to allow them to allocate different cloud resources to different budgets. Both were excellent requirements, so we built them into the core product.

Early 2010 was tough - too much work, too few people. But as we added to the team, the rate of adoption continued at a steady pace - still early adopters, mostly "tech-centric" companies and a lot of SaaS providers. By early Summer 2010, we began to sense a shift in the winds. More large companies were approaching us directly to help control "rogue" use of the public cloud; the private cloud platforms which we had been supporting since launch seemed to be picking up real deployment projects; large organizations seemed to be getting serious about deploying and managing hybrid environments that take advantage of "traditional" virtualization, and private clouds, ... and public clouds.

Which brings us to today. As we sit now, we see three distinct groups of customers driving our company: "tech-centric" adopters of public clouds, large companies building out their private cloud solutions, and the fast growing list of cloud-builders (turns out they need a management console for their solutions too). Included in this list is the largest telecommunications firm in Korea, KT. KT is leveraging enStratus to manage their private and public clouds.

Time will tell if this segmentation holds for long or if something new will shape the market. We do know it will be fun.

And through it all, not only do we and our customers love what we're doing, the industry is noticing as well. enStratus has been recognized with several awards this past year for its innovative technology and contribution to advancing the cloud computing industry. This includes the 2011 CRN Emerging Technology Vendor Award and the Editor's Choice for the best cloud application management solution by Cloudy Awards. enStratus was also identified as one of the Top Cloud Enablers Gaining Mind Share in 3Q 2011 by Ulitzer and was included in the Cloud Sourcing 100 Index as one of the leading cloud management solutions.