Thursday, August 25, 2011

Tracing the IT Evolution from the Big Bang to the Big Crunch

How enterprises are progressing from overgrown, difficult-to-manage IT systems to high performance open source infrastructure

Over the history of computing, we can trace a pattern of continuous decomposition, from a single system into disparate components. Early on, these individual parts made it easier to design, program and maintain systems, and meet the fast-growing demand for more power and more capacity.

The industry began with the mainframe, where the entire stack from hardware to application logic was contained in a single box. The next phase was the move from mainframe to client-server. This was followed by SOA (service-oriented architecture). This process of decomposition is a natural byproduct of growth in scale. As we consume increasingly more computing and storage, efficiency gains are achieved through specialization.

Such continuous decomposition is a typical pattern of many industries. Several centuries ago, the model was subsistence farming, where every family as a single unit grew all of their own crops. Today, food production has decomposed into a collection of highly specialized industries.

However, this process of decomposition in IT injects complexity. At a certain scale, highly decomposed systems become extremely challenging to manage. This then drives a pressing need to abstract away from some of the individual components to a higher level. This is largely what we are observing today with infrastructure computing. The complex mammoth of enterprise IT, today comprised of a spaghetti mix of application servers, relational and noSQL databases, messaging queues, caching and search services, etc., is no longer manageable.

Gartner labeled 2011 as the year of cloud platforms or PaaS. Thinking of PaaS, we intuitively think Heroku, Force.com, and Google App Engine, all off-premise cloud platforms. But the cloud movement is not just about on-premise versus off-premise. It's about creating an effective means to abstract away from application infrastructure complexity. As mainframes exploded into myriad sub-components, we experienced sort of a Big Bang in enterprise IT. What we are starting to observe now is the Big Crunch, turning application infrastructure back into a more unified, manageable artifact.

OpenStack

OpenStack is one of the most interesting initiatives topping the headlines during the last several months, and it's directly related to the Big Crunch. An open source project with the promise to help consolidate the many disparate components of application infrastructure, OpenStack is only a year old and is far from fulfilling this promise today. However, I believe that OpenStack for application infrastructure will eventually become what Linux became to application logic many years ago - a single interface unifying all application infrastructure components and exposing a standardized set of APIs to applications running on top of it.

Open Source Cloud Projects and How They Differ

OpenStack is not the first open source cloud project. Eucalyptus, OpenNebula, and Cloud.com all emerged before OpenStack and all of them are still very much alive. However, OpenStack is different from these others because it's the only one that has gained enough critical mass to get on a steady course to mass adoption.

What enabled OpenStack to reach this point was not an accident, but a clever strategy by RackSpace and other founding members. Rather than following a more common, vendor-centric approach to building an open source community, like Eucalyptus and Cloud.com did, RackSpace quickly figured out that getting a "cloud operating system" to mass adoption would require more marketing muscle then any single vendor has. So it positioned OpenStack as a decentralized, community-driven project from the very beginning and set out to get the support of big players in the application infrastructure space, namely Dell, Cisco, and Citrix. It didn't go after just any infrastructure player, but specifically focused on those who were arguably late to the cloud game and aching to make up the distance they lost to the likes of VMware and IBM. Ultimately, OpenStack's blitz to success is a result of unleashing an enormous amount of marketing energy in a short period of time, carefully coordinated between a number of application infrastructure power houses.

Following Amazon to Open Source Infrastructure

Today, OpenStack is focused on low level infrastructure services - compute, storage, image service, etc., and much work still remains to be done by the community in that area. However, we know the trend and have already seen it with Amazon Web Services (AWS). AWS initially started as Infrastructure as a Service (IaaS) with EC2 and S3 offerings; it then evolved into a fully blown Platform as a Service (PaaS). The value in solving application infrastructure complexity in a broader sense, by embedding higher level services like automated deployment, message queues, map reduce, and monitoring, is simply too compelling. At some point, we expect to see OpenStack creeping into the PaaS space, the same way AWS is doing today.

This gradual transition from simply being a compute and storage infrastructure orchestrator into a complete cloud operating system will happen naturally for OpenStack. It will be driven by infrastructure vendors of all sizes that are looking to plug their solutions into the OpenStack ecosystem. With more than 100 member companies on board already today, we see various announcements to this effect right and left: Gluster contributes its file system, Dell builds a deployment services, CloudCruiser builds a cost management solution, etc.

What's Ahead for OpenStack

The openness and decentralized nature of OpenStack is central to the realization of its vision of the cloud operating system. Instead of trying to solve all application infrastructure complexity inside one monolithic system, such as with the VMware stack, OpenStack harnesses the naturally occurring decomposition in the infrastructure space. This is the Big Bang in infrastructure we've all experienced. Individual vendors with competence in one particular area of application infrastructure can plug their solutions (storage, caching, monitoring, etc.) into OpenStack. As OpenStack continues to gain adoption, it will become a channel for infrastructure vendors to sell their offerings in the same way that the Apple app store is a channel for mobile app developers. At the same time, OpenStack will help abstract end users and resident applications away from the complexity of disparate infrastructure solutions.

Today we are still in the early days of OpenStack. It's far from being the ultimate platform. It may also be less feature-rich than competing offerings from Microsoft or VMware. However, this is unimportant today. What's important is that the need for the Big Crunch that will decrease application infrastructure complexity is obvious. The magnitude of effort required to make this happen is not something any single vendor could credibly pull off. Ultimately, it's not OpenStack features that matter, but the "idea" behind this project and the degree of uptake it has already received in the community. When many people come together to realize a sensible vision, that vision inevitably becomes a reality.

Tuesday, August 16, 2011

Our Contribution to the Vegas Economy

Here are the highlights on our corporate team-building in Vegas last week. Special thanks to Rachel and Athena for making this party happen. Thank you to all who participated and helped make it fun.





We started by warming up with some drinks in the airport bar on the way over to Vegas.





The luggage belt broke upon our arrival and it took over an hour to get our luggage. By then, the buzz from the airport bar session started to wear off… =(.





The taxi line outside the airport was loooong… so we decided to embellish our Vegas experience immediately by taking a limo to the hotel.





Finally arrived; herding around the Aria hotel entrance.

After a brief bite to eat in Vettro cafĂ© in Aria (which, by the way, is a horrible restaurant… don’t go there), we split up into two groups - the strong and the weak. The weak went to sleep or gamble. The strong went clubbing. Came back to the hotel room only at 4am.





The next morning, we woke up to this view; 51st floor in Aria. Don’t get too excited – as with many Vegas hotels, they don’t have floors 40-50 in Aria.





Breakfast… some people slept in late, so our ranks were slim at breakfast.





Ilya enjoyed his fries enormously!





Next stop – quintessential Vegas pool party at Liquid Lounge. $5 to anyone who can spot Mike Scherbakov and Julia Varigina in the crowd.





Why would anyone herd in the pool with 100 people in it, music blasting and no seating space, when you can quietly lounge next to one of 10 other pools in the hotel? The point of the pool party only comes to you after a few drinks… as you can see from the stampede by the bar, we were not the only ones to feel that way.





Once you get a drink in your hand – it’s BLAST OFF!





No comment.





Winding down at the pool… next stop: corporate dinner.





It was dark and all we had was a point and shoot… so not so many pictures at the dinner. But basically this is what it looked like.





After the dinner we went to watch a show – Absinthe. This group picture was taken immediately after.

11:48pm – time to split up again into gamblers and partiers. Since I belonged to the party group, you don’t get to see the pictures of the gamblers… sorry.





Second night of clubbing looked like this. 1:45am and Mike is asleep on a couch at Tryst. This is called a SHUT DOWN!





And my SHUT DOWN happened in the airport on the way back.

Friday, August 12, 2011

LDAP identity store for OpenStack Keystone

After some time working with OpenStack installation using existing LDAP installation for authentication, we encountered one big problem. The latest Dashboard code dropped support of old bare authentication in favor of Keystone-based one. That time Keystone had no support for multiple authentication backends, so we had to develop this feature.
Now we have a basic support of LDAP authentication in Keystone which provides subset of functionality that was present in Nova. Currently, the main limitation is inability to actually integrate with the existing LDAP tree due to limitations in backend, but it works fine in isolated corner of LDAP.
So, after a long time of coding and fighting with new upstream workflows, we can give you a chance to try it out.
To do it, one should:
  1. Make sure that all necessary components are installed. They are Nova, Glance, Keystone and Dashboard.

    Since the latter pair is still in incubator, you’ll have to download them from the source repository:
  2. Set up Nova to authorize requests in Keystone:

    It assumes that you’re in the same dir where you’ve downloaded Keystone sources. Replace nova.conf path if it differs in your Nova installation.
  3. Add schema information to your LDAP installation.

    It heavily depends on your LDAP server. There is a common .schema file and .ldif for the latest version of OpenLDAP in keystone/keystone/backends/ldap/ dir. For local OpenLDAP installation, this will do the trick (if you haven’t change the dir after previous steps):

  4. Modify Keystone configuration at keystone/etc/keystone.conf to use ldap backend:
    • add keystone.backends.ldap to the backends list in [DEFAULT] section;
    • remove Tenant, User, UserRoleAssociation and Token from the backend_entities list in [keystone.backends.sqlalchemy] section;
    • add new section (don’t forget to change URL, user and password to match your installation):
  5. Make sure that ou=Groups,dc=example,dc=com and ou=Users,dc=example,dc=com subtree exists or set LDAP backend to use any other ones by adding tenant_tree_dn, role_tree_dn and user_tree_dn parameters into [keystone.backends.ldap] section in config file.
  6. Run Nova, Keystone and Dashboard as usual.
  7. Create some users, tenants, endpoints, etc. in Keystone by using keystone/bin/keystone-manage command or just run keystone/bin/sample-data.sh to add the test ones.

  8. Now you can authenticate in Dashboard using credentials of one of created users. Note that from this point all user, project and role management should be done through Keystone using either keystone-manage command or syspanel on Dashboard.