News Stay informed about the latest enterprise technology news and product updates.

AWS enables DevOps culture, cloud-native app design

One startup embraces DevOps culture and cloud-native application design to produce a cutting-edge service on top of AWS.

Two phrases often heard in the Amazon Web Services world are DevOps culture and cloud-native applications. But what do they really mean in practice? And how can you achieve them in the real world?

One startup has combined both concepts to create an application that shows what can be done with Amazon Web Services (AWS) cloud.

Ekho Inc.'s eponymous application suite provides customers with various Focus sets of data mined from sources such as social media streams. This enables users to measure the performance of advertising and marketing campaigns, and to pre-target sales leads to reach the most likely buyers. Focus sets are presented to end users through their Web browsers.

Some days, mining social media streams can produce hundreds of millions of data points that Ekho's systems must shift through and analyze. Other days, the systems might see tens of thousands of data points instead. Being able to expand and contract the application and underlying AWS infrastructure lets Ekho manage such widely variable workloads, according to founder and CEO Kent Langley.

"Would we be here without Amazon? The answer is maybe," Langley said. "But it would have cost me orders-of-magnitude more money to get to the place where we are today and have the capacity that I have."

AWS, DevOps culture offer flexibility and low costs

Ekho runs about 32 Elastic Compute Cloud instances on average, a number that varies according to the workload. But that's only the tip of the iceberg: The computational instances access and analyze hundreds of millions of records in the AWS Simple Storage Service, or S3.

We had a client show up and say, 'We have to put 100 million rows of data in your database,' and I didn't have to go out and buy a single server.

The company also uses Glacier for long-term data storage, DynamoDB to store interim calculation results before final analysis is completed, Elasticache for the Redis in-memory database, the CloudFront content delivery network to make data sets perform well on users' browsers and the Simple Notification Service and Simple Email Service for internal operations.

Thanks to these services, Ekho runs very lean -- it employs a total of eight people, five of whom are in-house developers.

In Ekho's DevOps culture, application developers administer all of its operational services in addition to writing code to develop apps. "Between myself and my developers, we've been able to keep up very well," Langley said. "We didn't replace the operations role, we just distributed it among developers."

So, the small startup can still take on big jobs. "We had a client show up and say, 'We have to put 100 million rows of data in your database,' and I didn't have to go out and buy a single server," Langley said. "I spun up several and we expanded the size of a number of our core infrastructure components, we processed all that data into the core of our data tier, and we turned off all those servers when the job was done. It took two hours."

If Ekho was running a traditional data center infrastructure, Langley said he would probably have had to turn this opportunity down.

While Amazon's scalability is the substrate that enables DevOps agility, doing DevOps culture right is ultimately a matter of people and process that goes beyond technology, Langley said. In fact, at times the breadth and depth of Amazon's services can create more complexity than it solves. And as flexible as Amazon's infrastructure is, it takes the right application design to make full use of it.

The XYZs of scalability

Graceful scaling is the key to designing a cloud-native application, Langley said, and cited a book, The Art of Scalability, as inspiration for his company's application design. This book introduced Langley to the AKF Scalability Cube, which places scalability factors along three axes: x, y and z.

In this system, x-axis scalability refers to scaling out servers horizontally; y-axis scalability refers to vertical scaling; and z refers to data partitioning. "The key to being a cloud-native application is being scalable on all three of those axes," Langley said.

Ekho puts its own twist on y-axis scalability as well, Langley said. "Another way to think about y is application-level partitioning, and you'll often hear the term microservices architecture – that would be an example of y-axis partitioning, where you're breaking all the services down," he said.

With these scalability axioms in mind, and a combination of Java-based application design frameworks -- most notably, the Akka distributed application framework -- Ekho has designed its application so it can be partitioned among clusters of complete service pods. Those pods can then be put into multiple Amazon availability zones; multiple regions or multiple countries' regions; and availability zones for resiliency and disaster recovery, as well as for performance and scalability.

Moreover, "We are pursuing opportunities in Australia, Ireland and Brazil, and should either of them pass beyond an early stage and use a large amount of capacity, we'll simply replicate the entire application into the nearest regions scaling on the y axis," Langley said.

"The app is designed to do that."

Beth Pariseau is senior news writer for SearchAWS. Write to her at or follow @PariseauTT on Twitter.

Next Steps

Everything you need to know about cloud-native development

Dig Deeper on AWS big data and data analytics

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How do you design cloud-native applications?
Hi beth, good focus on cloud-native infrastructure and cloud-native services as a substrate for cloud-native application design.

I didn't see Ekho stakeholders talk about how they implemented core DevOps principles (i.e. automation, infrastructure as code, continuous delivery) on AWS. maybe a follow-up article opportunity?