February 26, 2013
I kind of feel sorry for Engine Yard sometime – once seen as one of the two best-known Platform as a Service offerings (alongside Heroku), the acquisition of Heroku by Salesforce kind of reduced Engine Yard’s visibility. The subsequent release of Cloud Foundry, and the significant uptake it has had in the marketplace have further dented the mind space that Engine Yard occupies. The company however hasn’t been resting, it continues to innovate and today is releasing a new approach to architecture that is designed to give its developer customers more control over their environment and more choices in terms of components, deployment options and infrastructure. The recently uncovered issues plaguing Heroku (or, as some would argue, the recent issues that were caused by insufficient understanding by Heroku customers) make this a timely announcement.
The company’s new architecture is being integrated into Engine Yard Cloud. The idea behind the new approach, is that developers will be able to more easily choose components and services offered by Engine Yard or include their own. In a pre-emptive strike against Heroku who, despite indications is yet to introduce hosting beyond Amazon Web services, Engine Yard’s multi-infrastructure support will allow developers to comparison shop for resources and select their preferred infrastructure provider in the future. In a following move to many Cloud Foundry players, developers also will be able to deploy in a public, private or hybrid cloud Finally this release see Engine Yard customers have access to an increasing variety of languages, operating systems, databases and more.
So – to specific functionality, this new release includes:
- Cluster model – developers can create purpose-built clusters for faster provisioning, configuration and deployment. Developers can currently run database clusters, and in the future, they will be able to deploy clusters of application and utility processes; clusters within an environment can be spread across multiple regions for disaster recovery
- Infrastructure abstraction – with an infrastructure abstraction layer now in place, developers will benefit from an increasing number of IaaS provider options in the future, as well as options for running on hybrid and private clouds
- Monitoring and Alerting – an automatic monitoring and alerting agent is now included with all new Engine Yard Cloud deployments. The new monitoring capabilities provide incident data on applications, components and other processes running on a developer’s virtual machine. In addition, alerts and monitoring information is available for virtual resources in the infrastructure, including CPU, memory and disk
- A new dynamic User Interface – the new UI provides a structured experience that helps developers build a stable architecture, as well as adapt to their growing resource needs
- New Blueprint Approach – three new blueprints allow developers to standardize their application environments using Engine Yard proven best practices. The new predefined blueprints give developers the flexibility to choose the size of their environments as well as add or remove clusters from an environment or components from clusters
More choice, more flexibility, more control – what’s not to like? At face value this should be a move which sees Engine Yard claw back recognition. The reality however is more nuanced than that – mind share and market attention go a long way to helping customers make their buying decisions, and Engine Yard is up against the might of Salesforce (pushing Heroku as the PaaS of choice) and the huge ecosystem forming behind Cloud Foundry. That said, Engine Yard does have a small but loyal following and their recent funding from Oracle should, so long as they make the right decisions, see them gain awareness in the larger enterprises that form Oracle’s customer base.
Beyond the softer measures of market success however are some bottom line issues – going by these, this release is a very strong move for Engine Yard. Enterprises are looking to platforms that meet their needs in terms of infrastructure and, more and more, this means that private or hybrid cloud are an important piece of the puzzle. likewise, despite enterprises being attracted to the PaaS story of “abstracting infrastructure away from the customer”, enterprises are still uncomfortable with not having fine grained control of their architecture and components – it’s a sensitive balancing act, ensuring automation and abstraction while still allowing for control. Time will tell whether Engine Yard have found the ideal balance point between these conflicting drivers. For more on the discussion of these two conflicting aims, see the excellent discussion about composable versus contextual systems by James Urquhart.