David L's Blog

Managenerds! Hire smart people and let them be smart!

I was having coffee with a good friend and engineer this morning, and we got onto the topic of “engineering management”. The actual term itself strikes fear into many peoples hearts, mainly because we can all relate to the rigid, unimaginative, bureaucrat manager that we’ve all had the misfortune to report to at some point in our careers. For me, it was a spineless jellyfish who had been promoted for his technical ability, not his managerial qualities, and his approach to management was to react when someone would complain to him about one of his team, then wheel out the policy documents as a way of correcting ones behavior… yes, take the time now to swallow whatever you just threw-up in your mouth.

The crux of our conversation was the point of view around whether you need engineering managers at all. My friends perspective (he works for a start-up in the Mountain View) was that good engineers don’t need managers, they know what needs to get done, and they do it. Therefor, managers where he works are just coordinators, making sure corporate rules and policies are drifting down to the talent. My position was a little more towards the mid-point; yes, you need managers, but no, not the crap ones.

The basis for my thinking was more from my experience playing football. My first junior team, what was definitely my dream team, was made up of some of the most talented players in our league. We used to get together and play pick-up matches, which were heaps of fun, but never once did we ever think we could play a “real” game without our coach! Why? Because the goals and objectives were different, and when you’re busy doing, you don’t have much time to look left or right, or in front of behind.

My belief is that, a good manager, not just a good engineering manager, is one that makes their team better, not by directing and ordering, but by coordinating and orchestrating. It definitely starts with a passion for people, and a passion for tackling things that require a team effort, but more importantly, it’s about helping people achieve their own goals and objectives, by helping them collaborate and work with others, so the total is greater than the sum of the parts. Back to looking in all directions; great engineering managers entrust their best and brightest (and lets face it, your whole team should be the best and brightest) to do the “work”, and provide the glue that brings all the folks doing stuff together against a common end-point. See, most organizations see managers as being the top of the tree, the best of the best, and this creates a structure which works great in well defined, heavily process oriented industries, but in engineering, where things are changing on a daily basis, expecting the person at the top to be the all knowing being is a recipe for disaster. At the same time, having no one play the role of coach, and trying to create a completely self-directed autonomous team, is dangerous. Don’t confuse autonomous individuals working as a team towards a unified outcome as being the same as an unmanaged self-directed team; the two are very different in my opinion.

So my advice to managers is, help your team by supporting them by unifying their vision on the outcome and endpoint, excite them to want to achieve the outcome together without resorting to the usual grab bag of motivations (money, power, shiny objects), let them own their wins and losses, and most importantly, throw away the policy book.

Because, if you’re going to hire smart people, let them be smart!

My “Business Impact of Cloud Computing” Session Video is Available!

A couple of weeks ago, I was very fortunate to be invited to OpenStack’s Design Summit for 2010, not only to attend and meet some amazing folks who I believe are at the leading edge of cloud computing, both as a technology shift but also as an emerging billion dollar industry, but to also speak on the topic of the business impact of cloud computing.

My Session and My Slides

The more I work with clients and business partners, the more passionate I become around the business transformation that becomes possible through cloud computing. As organizations start to embrace cloud technologies, and transform into on-demand businesses, the whole landscape of product and services supply and demand is changing, both through evolution and revolution. It’s so exciting!

Anyway, I hope you enjoy my session, and let me know what you think!?

Why Cloud is Traditional IT’s Ice-Age!

I get asked a lot by customers, “What is the big deal about cloud computing?”. It’s a totally fair question, given that most of the information about cloud computing has been about the potential market and revenue from cloud adoption. But that doesn’t go a great deal towards why it’s a good thing for companies to adopt.

There are three things that cloud, or the era of cloud, brings to the table that enables a vision of what I call the fully-automated Enterprise. The three key factors are:

• Virtualization
• Automation
• Business Function Integration

You need all of these things to achieve a fully-automated Enterprise via the cloud. Here’s why.

Virtualization only gets you part way there, in that, with virtualization, you can abstract the underlying resources away from the allocator, which is good because you can deal gracefully with failures, capacity demands, hot-spots, etc. But virtualization still requires a person to manage the request part, and identify how the virtual resources hang-together. This is not how consumers think, and it’s the biggest threat to traditional IT organizations. Consumers now think in terms of business function, or workloads, so rather than saying, “I need two SQL Servers and 10TB of storage”, they say, “I need to onboard two new employees”.

So automation becomes really important, because if you can’t map a resource set to a workload, and spin that up automagically, you can rapidly and efficiently respond to changing conditions and needs. Automation really supports the concept if self-service, which is a core part of a fully-automated Enterprise. It enables the business stakeholder to determine when and what they need, and not be concerned with how it happens. This is critical.

But this still implies the user/consumer/stakeholder has to perform some IT/systems specific action, such as, “I am onboarding two new employees, and I need two email accounts, access to the finance and ERP system, etc.”. This is generally additive to an existing core onboarding process. What is critical in the fully-automated Enterprise is the concept that the automated workload provisioning/management process is fully integrated into the business function. So, when you start the new employee onboarding workflow, part of the process contacts the main controller, assesses if this new set of employees can be supported by the current IT resources allocated, and if not, adjusts the resources to meet the demand, and integrates with other systems, such as charge-back systems for internal billing, etc.

This is where cloud in the Enterprise really makes sense. It changes the traditional conversation between the business and IT, from an “get me some boxes and install some software” to a “I need to respond to this business need”. Also, it helps abstract away allot of the minutia and detail from the user/consumer, so they can focus on doing business. And finally, it forces IT to become more agile, and to compete with commodity providers, because once customers start moving their critical workloads to true SaaS providers, where they are paying based on subscription or consumption, and their data is more secure and available than the SLA provided to them by IT, you’ll quickly see the full demise of IT orgs as we know it.

So there you have it. Embrace cloud, convert your Enterprise to be fully-automated, start thinking business function/service integration and not asset and resource management, and you’re going to survive the next IT ice-age!

Why the Windows Azure Nov 2010 SDK Rocks!!

So I’ve finally dug myself out of email and was able to sit down last night and check out the new Windows Azure Nov 2010 SDK, and ooowee, there are some humdingers in there.

Let’s start with Virtual Machine (VM) Role, which is as it says, the ability for you to create a VHD image that you can host in the cloud! Now, don’t get this confused with something like Amazon’s EC2 service, because it’s not. What it is though, is a way to get your application VM’s to a pre-configured OS state so you can deploy your service model onto. This is important for example, if you are migrating an existing application to Windows Azure, and that application has requirements/dependencies, both on the way the OS is configured (turning on/off certain features) or the need for a specific set of software libraries that need to be pre-installed before the app runs. All of these steps can be done offline in a VHD, then uploaded to Windows Azure, to be used by your service. You still need to use the service model though, but you get to select your own pre-configured VM image to run it on. You also can’t bank on things like persistent storage on your VM, as the VM still has to abide by all the rules a normal OS image does in Windows Azure, such as being restarted or torn down and redeployed somewhere else. Either way, this is an awesome feature.

Next on the list of coolness is Remote Desktop Access, and this is one that is very close to my heart as it’s one of the first hacks I wrote when I was on the Windows Azure engineering team, so am wrapped to see it has now become a full fledged feature. Nothing much needs to be said about this feature, you’re essentially able to RDP to a Windows Azure compute instance using your TS client, which is especially useful for troubleshooting and on the box debugging.

Another feature I’m over the moon about is Elevated Privileges, and again, one that’s close to my heart. The key scenario here is where you have a part of your application that needs to run for a set period of time (generally during a particular function) at a higher level of privilege. Take for example, if I have a part of my application that needs to invoke an administration function, like update a file in a secure location, when a user executes a particular feature. I don’t want to be at Admin level for the whole time my app is running, but I want to be able to elevate just for that period of time to execute my critical function, then drop back to steady state. This happens a lot in automated, virtual environments, when you don’t know what the environment looks like until run-time, so having this feature is a boon.

And finally, my most favorite feature, Virtual Network! This is the crux of how Windows Azure and Microsoft are going to be able to provide a converged cloud experience for customers. It’s an IP level technology where you can seamlessly connect your cloud assets with your on-premise assets to create a unified cloud solution. Think of being able to access a mission-critical backend database within your corporate firewall, from your highly-scalable Windows Azure instances!? Awesome!

So there you have it, just a quick round-up of my favorite parts of the new SDK, and while there are many more, I really recommend you spend some time checking the ones above out. Also, to get the VM Role and Virtual Network/Connect stuff running in the cloud, you’ll need to logon to the Windows Azure Management Portal, and sign-up for the beta.

Enjoy

Public versus Private Cloud is a NOOP Cloud Conversation!

If you’re about to have a cloud conversation with someone (a customer, an internal colleague), the worst thing you can do is dichotomize the conversation into public versus private cloud. And here’s why.

Most folks looking to adopt cloud computing are looking to do so from a transformative perspective. For example, if your organization can’t compete because your organization is too slow to respond to new opportunities or changing market conditions, and when traced back to the root cause, it’s because:

• IT still takes 6 weeks to stand-up a server, let alone get your app services up and running for the new business opportunity within a months
• The sales team need the IT app up and running before they can add new customer or pricing information
• The supply team need the IT folks and the sales folks to be done before they can add the new orders to the ERP system with the new SKU’s and pricing data for the new customers

Then tackling just the cloud conversation in terms of public or private is really not addressing the key issue, which is, how does the organization as a whole become an on-demand, always-on, 24/7 business.

When you ask this question, the answer to Private versus Public cloud becomes, both. You need a strategy that spans internal and external, because ensuring you have an on-demand internal IT capability, that is self-service and supple, that connects to a flexible, on-demand business organization, that can extend past the firewall, is how to deal with rapidly changing customer, market and internal business needs.

So make sure you cover all aspects of becoming an always-on organization, including how to leverage cloud computing internally and externally, and how it can serve as a transformative function against other business units, or you’re just getting a small part of all the goodness cloud can offer.

Choose your Cloud on Capability, Not Cost!

For those following the cloud computing movement, a common question arises after some level of contemplation… “I’m paying for what?”.

This is a tough question to answer, because depending on what kind of cloud service your consuming, you could be paying for infrastructure, platform, or service. Say you get past this point, and understand what kind of cloud service your consuming, the next question that pops up is, “How do I select a provider?”.

This inevitably leads down the cost path, and for me, this is where the road gets slippery. Driving costs down on a seemingly commodity service is non-trivial, but not impossible either. Negotiating better prices on your supply services, or becoming more operationally efficient, are well understood techniques for lowering your bottom line, and these savings can be passed onto the customer. But the tricky part of cloud is, it’s just not about providing the fungible. For example, we’re not talking about a standardized service like power, or a true fungible like wool. Using the power analogy is flawed, mainly because power has a specific exit criteria, the output voltage. You either get your target voltage or not, so who cares whether the actual core provider uses hydro, nuclear, or coal? And, switching providers based on cost is easy, it’s not like you need to swap your toaster or microwave oven. And for wool, it’s the same. Wool (for all intents and purposes) is wool, so trading in a commodity market is easy, because the transformation of that commodity is also standardized. I can buy wool from multiple providers, put it through my production process, and still product a yield with little change to my production process.

Cloud is not the same. While you could argue that two IaaS providers of a Windows VM are commodity, in fact, they are not. They more than likely have different API’s, different mechanisms for billing you, different SLA’s, different baked in technology models (load balances, security appliances, etc), different levels of compliance (SAS70, etc), different physical locations (San Francisco, New York). All of these things prevent them from meeting the commodity bar, and by no means are they truly interchangeable or fungible.

So why is this important? Because selecting cloud providers purely on cost is a poor technique. What you should be selecting a cloud provider on is capability. Matching your requirements to a providers capabilities, and their capability roadmap, ensures you receive the service you need to meet your goals and objectives now and down the path, where cost is a factor, but not the deciding attribute.

This also points to the the course for many cloud providers, and that is to move away from the commodity market and move towards high-value, capability driven cloud service offerings.

So next time the conversation of clouds and costs come up, throw the capabilities card down, and see what happens?

Why Vertical Clouds Are The Future!

Over the last two and a half years I’ve spent in the cloud space, one question that has always concerned me has been, “Is there money in cloud computing?”. I ask it from a provider perspective, as I think there is a lot of money to be made in the cloud ecosystem, but as a direct cloud service provider, is there money to be made.

I think there is, but I don’t think it’s going to be as a commodity platform provider. Why? Because there are just too many business issues that aren’t addressed by cloud computing providers to date.

See, if you’re a business, and you’re looking to make money by offering a service via the web, by leveraging a cloud platform, you’ll need some basic business capabilities. Let’s use tax as a good example. States are permitted to enact their own tax laws, as is the federal government. They don’t have to agree on a standard, meaning one state might declare that tax is applicable if a service is delivered to a resident in their state, while another might declare that tax is applicable if the service is provided out of their state. So as a service provider, you’re going to need some fine grained insight into what’s happening with your service. Let’s keep moving forward with this example. If you are hosting your service with a cloud provider that has two data centers, in different states. Let’s say that for one part of the month, your service is running out of state x. Then something happens, and for a period of time, your service is moved to data center y, and your service is served out of there. Then, the something is fixed, and your service moves back to data center x. Both data centers are in the providers “region a”, just in different states. This introduces a complexity, because what happens if state y considers your tax liability to be based on if you ran a service out of their state? And if you didn’t know your service was running in state x, because the bill you get from the service provider simply says “region a”, you might be in a sticky situation.

Again, this is why purely generic, commodity clouds are a challenge. They don’t have enough “business smarts” baked in, to help you as the customer, stay compliant. It’s not that they need to be tax smart, but they at least need to let you be tax smart.

Taxation is just one area of complexity, compliance is another. For example, what if you’re trying to develop a service to sell to financial services customers? There are a myriad of compliance requirements that financial services customers have. If your service doesn’t support your customers in being compliant, then that’s going to be an insurmountable barrier to them buying your service. And, if you try and use a cloud platform provider who doesn’t have the requisite hooks in place for you to build the controls required to offer compliance, the whole venture is a non-starter.

This is why I think vertical clouds are the future. See, right now, buying and connecting up servers is not a challenge, money is the only factor here. However, standing up a truly automated cloud, one that can dynamically allocate resources based on demand, like the big players have, is far harder, mainly because there aren’t many tried and true options out there. OpenStack is definitely an interesting option, as it’s open source, demonstrated (NASA and RackSpace use it), and provides all the bits you need to get a commodity cloud up and running. OK, so now I have the platform in place, and it’s open source and pluggable, now I have some room to move. So say I decide I’m going to be the premier provider of cloud platform services to the financial services industry. I go a build a bunch of goodies into the base platform that supports all the compliance requirements (tax, legal, etc.) of my industry (same applies to healthcare, etc). Wow, now I have something interesting, because now I can offer customers a high-value cloud platform service that makes it easy for them to do business. What’s more, the future of cloud is absolutely composability and redundancy, so I may have an app that has a financial services capability delivered by FinCloudX and a healthcare capability delivered by HealthCloudY. Ahhhh. And, all the appropriate compliance requirements are taken care of by each cloud.

What do you think?

Oooh, Cloud + Mobile + Analytics

So Gartner released it’s Top 10 Strategic Technologies for 2011 yesterday, and I had to jump on the back with some of my own observations.

Now, the lens I’m looking at Gartner’s list with is heavily based on my last 30 days at PwC. When we think about Cloud Computing @ PwC, which happens to be #1 on Gartner’s list, we tend to think about it in a slightly different way to most.

See, Cloud to us is an instrument, a technique, a mindset, I mean, let’s go all out, it’s a lifestyle. We take some of the smartest folks in leading business verticals, like Finance or Media & Entertainment for example, and challenge them to identify new ways of doing business where cloud computing (and other leading technologies by the way) is a key enabler. This leads to some amazing ideas and business outcomes!

When I look at the Gartner list, three things jump out at me. Cloud obviously, and I think Garner is right on the money when they suggest a lot of the action will happen in understanding how to select a cloud provider and how to maintain cloud services from a governance and policy perspective. Mobile is a logical extension of the cloud paradigm shift; if you start moving massive computing to the utility domain, then more immersive, intimate mobile devices are key. Business and lifestyle now collapse onto each other, and you need a mobile computing platform that can not only provide you with a meaningful social experience, but also one that is cognizant and capable from a business point of view. And finally, analytics. Well, my time at Live Labs and Windows Azure taught me one thing, if you can get lots of machines, talking to lots of other services (like Twitter, Bing, etc), and use that to correlate your own information needs, you’re on a winner. Being able to qualify a factoid against the web and social corpus, at real-time speed, directly from your palm, is infinitely powerful.

I’m also going to add in Interactive Experiences as a leading area, I mean, Kinect creates amazing possibilities in this area.

I’m super excited about where Cloud, Mobile and Analytics will intersect in 2011. What about you?

Stacks On! OpenStack and the Cloud!

If you’ve been working/following/doing stuff in the cloud for the past few years, you’ll know how complicated it is to get an end to end service experience going. It’s not that there is anything fundamentally wrong with the cloud, it’s just that it’s an emerging technology and business discipline, and as such, has many incarnations and approaches.

This morning I had the chance to chat with Jim Curry and Jonathan Bryce about OpenStack and what it means for cloud computing. For those that aren’t familiar with OpenStack, it’s a set of open source software projects that provide compute and storage services for users to construct a cloud platform.

What’s fantastic about OpenStack is it focuses on the toughest part of cloud computing from a platform perspective, and uses the force of the community to solve that problem. When you look at a cloud platform, you have some basic parts:

You have hardware, because you need some metal to run stuff on, some network gear to plumb it out to the Interworld, and some other stuff for power, cooling, whatever.

You have a hypervisor, because without one, you can’t virtualize the metal, and that’s kind of like sewing your shoes to your pants, and that’s not good, unless you live in <insert backward town of your choice here>.

And then finally, you have virtual machines/containers/guest OS, whatever, that run the actual compute workload.

But… and it’s a very big but (yes, yes, ha ha), you need something that manages all of this. I mean, you don’t want Larry having to push a button and deploy a new machine/container manually, or monitor all the tenants manually, so you need something more, think of it as the ghost in the machine. Well, this part is really hard to build, and test, and deploy. This is what I love about the OpenStack model, their OpenStack Compute project is all about taking care of this part. And, it already supports KVM, Xen, and VirtualBox!

The other part of your platform is your storage stuff. Again, not easy to build, especially when you’re trying to distribute failure points across the cluster in a way that is fault tolerant and performant. OpenStack has a project for that too, OpenStack Object Storage. 

And, it’s all open source. It is! Go check out the code for yourself!

Very exciting stuff when you think about taking advantage of a cloud based environment for dynamic workload management and managed recovery.

No Business, No Cloud, Vice Versa!

Over the past few weeks, I’ve had a bunch of great conversations regarding how organizations should start to prepare for delivering cloud services.

One aspect which continually pops up as a blind spot is the relationship of the business on the cloud service. In this post, I’m going to use some of my own science to describe one of the key elements every cloud service provider needs to think about, and that’s business.

In the traditional software market, the product pipeline is pretty much serial. You can rearrange the blocks how you like, but for a majority of the companies I’ve worked with, things move in a linear sequence, that looks something like this:

This was fine when iterating between the steps to get the product right was part of the schedule, and releasing a product took 2-3 years. But as we’ll see with cloud, this is not the case anymore. Speed to market, and a very mobile customer segment means you may not get a second bit at the cherry, so you better ship a quality, meaningful service day 1, or go home.

The second issue is based on the perception many engineering teams have around features and requirements. In the glory days of software, when software was sufficiently far away from the customer and their business needs, designing features which were wholly value-add was very achievable. Let me use the early operating systems. When no one used computers, and very few knew what their value could be, creating software in a vacuum was the norm. When you released said product, the marketplace responded favorably. And they could use these new tools to help in back office functions or administrative functions, which were far more about utility and administrative efficiency than business function or value.

This has changed significantly though, and now, the distance between technology and the customer from a business perspective is far shorter, which means the infusion of business necessary features are as important, if not more, than standard plumbing style features no matter how value-add they may be.

This brings me to the feature lifecycle, as it relates to cloud based services. The initial product backlog needs to be derived from two different interactions with customers. The first is based on what they “want"”:

This is all about identifying the features that will entice the customer into selecting your technology over any one else’s, or motivate their buying decision over what they have today. These could be business level features or infrastructure features, but here comes the rub, these mean nothing without the table stakes of cloud computing, the “have” features.

In business, there are imperatives that in today’s software market, where technology is no longer a back office enabler but a critical success factor to most organizations, must be part of a cloud service. What do I mean by this? Take compliance for example. If you are about to deliver a cloud service that deals with peoples personal data, you better make sure somewhere in your service stack, is the ability to demonstrate compliance with the laws and regulations that involve peoples personally identifiable information. Ignorance as many of us know from watching Law and Order is not a defensible position. You either need to ensure your service complies, or your platform provider has compliance already baked in, or you push this requirement onto the customer. And while cloud services rock in terms of composability, it’s like buying a car with no seat belts. Sure, I could drill some holes in my new Ferrari and attach some rope, and probably be compliant, but I’m pretty sure me and every other customer would rather see this kind of “feature” added at the factory. New wheels on the other hand, could go either way. So if you get to the decision point of whether business imperative feature x is your responsibility or someone else’s, just ask yourself, how many of our customers are going to demand this as a min bar requirement, and is it easier for us to implement it once for everyone or not.

So where does all this hub bub leave us? A pretty simple model, we take the current serial approach, and like good little distributed cloud engineers, we parallelize it:

What we get is a far more rapid, business aligned, service release model. It means we can setup multiple instances of this for multiple features, so the longer and shorter ones don’t get tied up unless there are blocking dependencies. We also ensure the time to market is shorter. And those table stakes we spoke of before, are able to be shipped quickly to get the customers lining up, while still having a cadence for more enticing, value-add features, built on the solid service base.

Now I agree, it sounds kind of simple, and while I agree that there is much hard work required in the background, especially from the discipline and governance perspective, but the great thing is, with the right amount of planning up-front, getting this into you organization is completely achievable.

As always, I would love to hear your thoughts on this.