All posts by Alberto Arias Maestro

Mind the Gap: Innovating in the Cloud with APIs

If you’ve ever traveled London by the underground tube, you’ve likely heard the station speakers announce “mind the gap.” They’re warning you of a gap between the train and the platform. But why build a curved train platform in the first place? Were the engineers not aware of its dangers?


Bridging Decades of Software Gap

Now, London is an old city. Generations of engineers and architects have added their vision to the city’s foundation. Our software industry is not as old, but in comparison has seen such fast paced innovation and reinvention that it has generated decades of software on which our modern civilization is built. As a result, the only way to bridge the gap between decades of generated software is to build the equivalent of a curved station.

It’s hard to look both forward and back at the same time. For years as they combined old with new technology–ranging from hardware to application runtimes–IT tried to stabilize operations with very little room for error. That stabilizing process has been arduous and expensive.

On the other hand, the software development process is marked by continual change. Most organizations reconciled the operations and development worlds by introducing release cycles measured in years, even naming their products based on the year it was released. This was much like how a car manufacturer brings a new model each year to market.

Standardizing the Cloud with Infrastructure APIs

Then came the Cloud, which challenged everything. It commoditized the infrastructure on which applications ran. That not only reduced operations, but questioned the standard model we had been operating on. Cloud pioneers must have felt like Copernicus with the way the industry reacted when they claimed that if infrastructure can be standardized, everything else can.

However standardizing doesn’t mean we’ve to rebuild everything, neither does it mean that to innovatively develop software, we should adhere strictly to platforms. Looking back, a lot of the innovation that happened over the past few years is indeed the result of combining technologies in ways no one thought of before.

For cloud providers, this innovation is in the form of infrastructure APIs. As the APIs bring more sophistication, control, and flexibility, there’s a greater need to stabilize and standardize.

Products like ElasticBox thrive in standardizing software operations. You can think of ElasticBox as the logistics platform for your software development and operations.

Someone’s Infrastructure is Someone Else’s Service

These days where everything is offered up “as a service,” we run the risk of turning “as a service” into a meaningless marketing tag. Most everyday someone out there comes up with a new “as a service” offering forcing even the government to officiate guidelines for IaaS, PaaS, and SaaS. In this blog, I’d like to explore the true meaning of Infrastructure as a Service (IaaS) and see what it means for us as enterprises and developers.

What does IaaS mean?

As defined by the government, Infrastructure as a Service allows consumers to provision processing, storage, network, and other fundamental computing resources on demand. To these provisioned resources, consumers can deploy and run arbitrary software including operating systems and applications. Without having to manage or worry about the underlying cloud infrastructure, consumers can control operating systems, storage, their deployed applications, and even in some limited way control networking components like host firewalls.

Before Amazon’s EC2 offering, many hosting companies like Rackspace had already offered compute resources on demand. But what’s so different about the AWS offering that triggered a whole IT revolution?

Why’s Amazon IaaS Strategy Successful?

I believe the difference is rooted in Amazon’s service centered culture as revealed in Steve Yegge’s post and most recently in Brad Stone’s book, The Everything Store. Jeff Bezos’ crusade to be efficient has a tremendous impact on how individuals and teams communicate at Amazon where everything is an interface. Even meetings are conducted on a very well defined contract (no PowerPoint presentations but a 7-page write-up instead). So how does this approach make AWS the market leader in cloud computing? The answer lies in how Amazon’s internal organization is designed upon Service Oriented Architecture principles. At Amazon, every team communicates using well-defined interfaces that are abstracted from the implementation. As a result, today we’re all just one more team within Amazon—this is not just great customer support, but goes beyond where we’re all in the same boat as Amazon consuming the same service as them.

How to be Service Oriented Like Netflix?

With its service-oriented philosophy, AWS has liberated us from mundane infrastructure details and forced us to focus on what really matters. This trend could not be better represented than by Netflix, a company that realized the potential of shifting its focus to its core business so successfully that it’s become the canonical example of the potential of cloud computing.

In reality, it’s not important whether your strategy is IaaS, PaaS, or SaaS. What matters is that you’re able to change the mental model and operate as a service organization requires. The amount of commitment to this philosophy will determine the right strategy for you. The less you care about implementation details, the higher in the services stack is your insertion point. I personally believe the higher you start, the higher you reach.

What do Services in Context Mean for You?

At ElasticBox, we build the tools that allow enterprises and individuals to truly operate as a service. We help shift focus from implementing interfaces to collaborating with interfaces and from merely controlling interfaces to using them in context. This means anything can be a service whether it’s a platform or a low-level infrastructure resource, as long as its function is well defined through an interface, and it abstracts users from its implementation. How these services should be used is not determined by control, but by context ultimately powering the user to make their own decisions.

Follow-Up to VMworld Barcelona: Boost Cloud Usage and Automate Deployments

After a packed week at VMworld Barcelona, it’s time to share some highlights as promised in my earlier post.

All kinds of VMware customers thronged to our ElasticBox booth: People from large enterprises, small companies, service providers, and system integrators. A question that repeatedly came up in conversations was: “How is it possible to manage my applications in the cloud without directly managing the server infrastructure?”

Applications in Enterprise Virtualized Private Networks

Many EU companies manage applications in virtualized networks, on private clouds than on public. The reasons for the slow move to the public cloud are not surprising. Data privacy is a chief concern. Beyond EU government regulations, there are other security needs around availability, scalability, and latency as well.

To illustrate this point, consider how most enterprise applications are built in the private cloud with a certain redundancy in mind. When you deploy to a server, you put a lot of processes in place to guarantee its uptime. You run the server in a cluster with duplicated storage, snapshots and data backups. That’s a lot of complex processes built around server infrastructure just to keep it alive. After investing so much time and money on achieving this state of availability, whether or not you use the server, you don’t want to touch it. Now in such a scenario, you’re really not making use of the cloud.

Take another example. AWS is elastic and provides services on demand. So you ideally use it only as you need to. But if you go create a number of servers on AWS that are always turned on whether or not your applications are using them, then it’s not a cloud. In this case, you’re just using AWS as a hosting provider. You’re simply re-hosting your servers on AWS.

True Usage of the Cloud

To me it’s a cloud when infrastructure is a service that you use only when you need it. The cloud should fulfill your demand for infrastructure in an automated and elastic fashion.

When infrastructure is a service, you don’t want to manage it. You want to consume. Much like renting a car. You rent when you need to ride. You’re not going to pay 100 bucks a day just to rent and park the car in your garage. Also if the rental needs a tune up or an oil change, you shouldn’t be the one doing it. You just want to drive and not worry about anything else. The same goes for managing servers. The thinking is I don’t want to put all that effort into maintaining that server, which is like changing the oil on a rental car. I just want to use the server when I need it. When you rent infrastructure in the cloud, you shouldn’t have to manage the servers. You don’t want to be logging into servers and installing software manually.

At ElasticBox, we give you the tools to manage your infrastructure from the point of view of your applications. We have built in tasks to routinely manage the lifecycle of your applications. Based on the data you provide of the application and how you define the application, we manage the infrastructure with the cloud provider of your choice–public, private, or hybrid.

Automating Deployment Processes

Other interesting deployment scenarios were from system integrators. Their main challenge is they spend a lot of time automating server infrastructure, managing virtual servers, and learning new tools from different providers. They realize they replicate the processes for managing applications across multiple clouds. It makes them focus less on the needs of the applications and more on managing the infrastructure. In a way, it defeats the purpose of why they got on the cloud in the first place!

For example, even with a single cloud provider and the same infrastructure, it’s a challenge to maintain separate environments for dev, test, and production because of the amount of duplicate effort involved. The way ElasticBox looks at it, the difference between the dev, test, and production environments is a matter of different policies. While an application in a production environment has regulatory, reliability, and disaster recovery needs, the same application a dev environment doesn’t have them. The application itself doesn’t inherently change across these different environments. It’s the same application just run in a different way. It’s how it’s run that changes. And if the ‘how’ is automated then it’s truly easy to deploy applications in the cloud.

The New Cloud Mantra

The new paradigm shift in cloud deployments is to manage deployments from an application point of view instead of the infrastructure point of view. The shift has already happened before in the way we moved from managing infrastructure in physical machines to virtual machines.

So instead of defining processes to manage infrastructure across multiple clouds, you just define the way you want your applications to run and let the system take care of managing the server infrastructure for you based on demand and policies. If your infrastructure changes, you don’t have to change the application needs or your policies. What need to be updated are the management tools to leverage the new capabilities. And that’s what ElasticBox does. We provide the service to automate the management processes so that you can focus on the needs of your application and the control the policies that dictate who should use the cloud resources and how much of it.

This is the message that resonates very clearly with the companies that are trying to run applications on infrastructure across multiple cloud providers.

We allow you to focus one level up. Above the infrastructure management tools. What you do is define applications you want to run and then rent the technology that will automate the process of managing the low-level infrastructure to run the applications. To focus on the application level–now that’s the power customers really want.



Hello from Vmworld 2013 Barcelona

It’s day 3 at Vmworld 2013 in Barcelona and there’s a lot going on. ElasticBox is creating a ton of buzz here as several VMware customers are walking by our booth to learn how ElasticBox can automate and efficiently improve the flow of their cloud deployments.

Only just a month ago, we won the finalist award for Best of Vmworld 2013 in San Francisco. Building on that momentum, we are at Vmworld Barcelona to deliver on our commitment to VMware, the market leader in the virtualization space that’s transforming IT.  We’re meeting VMworld attendees and customers to understand their cloud deployment use cases and see how ElasticBox can guide their journey.

I’ve been talking to a number of prospects and giving demos of ElasticBox. People are excited when I show them how ElasticBox can extend their enterprise cloud capabilities. We empower enterprises to decouple applications from the underlying infrastructure. Added to that, enterprises can deploy to the private, public, or hybrid cloud unhindered while we handle the lifecycle of configuring the applications seamlessly. They can merge the capabilities of the private cloud through VMware’s vSphere and vCenter and integrate with the public cloud through vCloud hybrid or AWS, Azure, Google Compute Engine, and HP Cloud.

It’s interesting to note the unique challenges and deployment scenarios in the EU market. I’ll dive into that in the coming days in a separate post. In the meantime, it’s wonderful to engage with the VMworld attendees, CIOs, and developers alike and absorb all this energy and excitement.

Signing off from Barcelona. Buenas noches.

What is an Application?

The other day a colleague and I got into a heated discussion regarding the definition of an enterprise application. He contended that each server hosted 1 or more apps which combined to make an “application stack”. I on the other hand defined an app as all of the components needed to effectively provide a service, regardless of how many servers they were spread across.

It seems like a silly argument I know. You’d be right to say “Who cares as long as it works?” I mean, at the end of the day the only thing that’s important is that the business is getting the service they need right?

Right, and that’s the problem. You see, I realized then that I had the benefit of seeing the world through service assurance tinted lenses. For better or worse I spent 7 years getting more intimate than I wanted to with CMDBs, service models, SLAs, KPIs, etc.. and like the people running the NOC I now viewed the app holistically rather than as a collection of parts. My friend on the other hand hadn’t made this leap and was still thinking in terms of projects, which got me thinking…

Read More