devopsy.kinsta.cloud

Tag: scale

The 8 “why’s” of Cloud
Myself and the gang have been talking about Cloud a lot recently as we are embarking on a multi-year journey. Cloud is fashionable but is this another cool toy for the techies? As an architect I think the most powerful question in my toolbox is “why”.
- Why are we doing this?
- Does it add business value?
- What are we trying to achieve?
As IT folk it’s instinctive to go straight into the “how” but its the “why” that is the really important question. Get that right and how to do it should be relatively easy. A solution is much easier to put in place if you’ve really captured and understood what it is you are trying to accomplish. I think there are 8 reasons why companies commonly move the Cloud – I’m specifically thinking about IaaS and PaaS here but I guess this also could apply to SaaS in parts.

Scale

The massive amounts of processing power or data storage that public Cloud offerings can achieve would be difficult to achieve building your own solutions (certainly at any kind of realistic price point).

Elasticity

The ability to expand and contract resources (such as compute) depending on your requirements. Traditional IT departments buy capacity in advance which is unused until it is required. The elasticity of Cloud allows us to buy what we want, when we need it and not be constrained by fixed overheads.

Cost saving/model

Some companies believe that moving to the Cloud will save them money.

I think the ROI for Cloud is really difficult to ascertain though. How do you compare apples for apples when Cloud is a different model to on-premise?

It might be easy to say a server costs X to run each year (power, data centre costs, depreciation, support etc) and compare that to a Cloud server. However, what is the cost of having to wait for 3 weeks to get a new server on-premise when you can get it in 5 minutes in the Cloud?

It’s not an easy calculation to be made and I don’t think I’ve seen a really convincing argument from either side.

One insurance company I know said they did some calculations and Cloud was 3x more expensive than on-premise. I’ve seen Cloud companies boast that IaaS is 3x cheaper than on-premise. You should do some due diligence on the cost of Cloud of course. However, in my eyes it’s too complicated and fuzzy to create a compelling story at the moment. Does this mean you shouldn’t move to the Cloud? Absolutely not – but focus on the other benefits too as cost alone is too difficult to accurately determine. The move from CapEx to OpEx is also a difficult question for many and really needs to be thought about. How do you accurately budget for a service if you are using the elasticity and scale features of the Cloud for example?

Future proofing

The rate of new features hitting Cloud providers is pretty astounding. AWS for example have over 450 services now and more hit the shelves every month. You probably won’t need the majority of these features now but what about in the future? As an IT department we can’t predict the future but we can help to respond to it. Why build it yourself when you can buy it as a commodity?

Time to market

With Cloud being pre-packaged and largely automated the time to market for adopting resources is often significantly lower than doing it yourself. You might have a really neat automated server build at your company but chances are you still need to wait for the storage guy or the network guy to do something. Often its not even the time waiting for something to be spun up – its the time waiting for a person to become available in order to press the button to spin it up. For example, in my company it takes 2 hours to build a VM. However I might not be able to book a resource to kick the process off for 2-3 weeks depending on their availability. I don’t think this is a problem that only public Cloud can remedy but again why build it internally?

Resilience

This is a bit contentious but bear with me. Cloud outages happen. On-premise outages happen. However, I would argue that due to the scale of some of things like Azure (and the ease of employing it) that cloud is more resilient than traditionally hosted IT. But…. Only if your application is written/configured in such a way to take advantage of the multiple availability zones and the resilient functionality that Cloud providers…..errrm….provide. If you simply lift and shift from on-premise to Cloud you are just moving the problem. If you treat Cloud just like another data centre you’ll get just another data centre with much the same problems as you currently have. Perhaps even worse. At least in your data centre if there is a problem you are in charge of your infrastructure guys and can prioritise (shout at) them. What is going to happen when you are speck on the Azure infrastructure? Is your voice going to get heard? Is it heck.

Increasing competitive advantage

Although there is value getting your IT teams to run infrastructure (it’s likely your business couldn’t operate without it), does they offer competitive advantage? What competitive advantage do you realistically gain over your rivals by running your own SAN, servers etc? Wouldn’t it be better if your teams were concentrating on high-value tasks that separate you from competitors rather than undifferentiated heavy lifting? Competitive advantage can be realised through such things as…
1. Lowering costs
2. Improving quality
3. Increasing the pace of change
4. Improving end user support
5. Innovation
6. Spending more time understanding the business
Wouldn’t you want your teams spending time on the above rather than worrying about provisioning blades and making sure backup tapes get revolved?

Geographic reach

As companies grow and their worldwide reach increases (customers and internally) then it means getting data closer to the end user.
- Your Google ranking is probably going to suffer in the US if you are serving your website from the UK.
- Your Citrix session is likely to be “sub-optimal” if you are sat in London trying to access your VDI farm in Australia.
- How do you organise downtime for maintenance when your worldwide presence is open 24×7 because of your global reach?
The global reach of public Cloud companies enables to provision resources nearer the people that need them.

A word of warning

In order to fully realise the benefits of the Cloud (such as scale, resilience) applications need to be architected accordingly. You are unlikely to realise the benefits I’ve talked about simply through “lift and shift”. It’s also worth mentioning that people, process, technology, culture all need to be addressed as part of the a Cloud adoption. This isn’t just a technical exercise and nor is Cloud a panacea for all of the challenges that face IT.
April 10, 2015
The Trouble With Enterprise DevOps

The literary world and beyond has been up in arms as of late regarding the use of the word ‘literally’. It seems that many are using the word literally when they mean figuratively. For example, if you say, “I literally split my pants laughing,” it would be plausible for one to look at your pants looking for a tear. Words are funny that way. When used to emphasize the action or outcome, some will take literary privilege. Enterprise is also one of those words that are used to convey emphasis often with disregard to the implied meaning.

When it comes to DevOps there has been a lot of debate about the modifier ‘enterprise’. Modifiers are supposed to add specificity to the noun it is modifying. Agreeably, enterprise is a horrible modifier for DevOps when used without additional modifiers representing scale. I have been, and continue to be, a big advocate of the concept of Enterprise DevOps. That said, I too have been remiss in my use of the word enterprise to further modify with the term ‘large-scale.’

I don’t remember exactly what triggered me to seek out if the word enterprise implied large, but when I did I was surprised to find that there is no implied meaning that enterprise means large and, in fact, can be modified with small-, medium- and large-scale to represent the appropriate size. As further evidence to the ambiguity of the use of the word enterprise, I worked for a company that divided their sales organization into enterprise and commercial accounts. Clearly, this organization believes that enterprise connotes large-scale since this group was responsible for selling to a specific class of customer that spent a significant amount of money with them. In this case, scale was identified by how much money the business spent with that vendor versus annual revenues versus number of employees. So, clearly, not only does the word enterprise not imply scale, but it also has different metrics that will determine the scale of an enterprise.

Merriam-Webster defines Enterprise as follows:

en·ter·prise

noun
\ˈen-tə(r)-ˌprīz\

: a project or activity that involves many people and that is often difficult

: a business organization

: the ability or desire to do dangerous or difficult things or to solve problems in new ways

Obviously, none of these meanings relate to size or scale, but two of the meanings do indicate difficulty. Let’s put that in the parking lot for later.

Why is this important? With regard to IT, I believe there is a tendency to throw around the word enterprise with no modifiers when we mean large-scale. For example, “Enterprise Software” is a term that is often used to describe very expensive and complex software applications that are designed to operate at the scale of the entire business versus the individual. Typically, the software described by enterprise software is found in mid- to large-scale enterprises where they can afford to acquire, configure and operate this type of software. Likewise, “Enterprise Storage” is a way to describe compute data storage environments for large organizations.

Likewise, “Enterprise DevOps” is a term that that is often used to represent adoption of DevOps practices in large, complex organizations with many different stakeholders and sub-organizations making it much more difficult to coordinate efforts around efforts like continuous delivery and continuous improvement.

Interestingly, and I believe accidentally, implementing enterprise software and adopting enterprise DevOps are difficult projects. So, based on our Webster’s definition, enterprise works as a modifier for these nouns. But there’s still the issue that for small-, mid- and large-scale enterprises the challenges and hurdles associated with DevOps adoption vary enough that the constraints and bottlenecks require different approaches to remove. This is especially true of large-scale global enterprises where development exists in four continents, operations data centers exist in multiple countries on four continents and the business operates in six continents with a comprised IT staff of 120,000 people.

I for one will be very careful in the future to define what I mean when I’m using the word enterprise in the future. If I’m talking about large-scale enterprises, which I usually am, I will make sure that early on in my writings and presentations I specify that when you see enterprise going forward I’m talking about large-scale enterprises.

January 23, 2015
Automating code helps businesses adapt to customer demand quickly

This is the first article in a series of pieces on digital innovation, accelerating change and the rise of the coded business from innovators in the Chef (click here) community.

How does the need for speed and scale affect businesses today?

Let’s start with scale. As a technology company grows, its infrastructure grows – more machines (or machine images), more networking, more data storage needs, more code, more developers, and more users. The only way to scale with growth is with automation. And, as more and more of the world’s interactions happen online (be it commercial transactions, email, social networking, video streaming, etc.), that scale of infrastructure is breaking records all the time. With these new levels of scale come ever-increasing automation requirements.

On the speed side, first-to-market has always been an important part of business – but what that means has evolved. It’s no longer simply about producing that new cool item before the other guys. Now it also means you must be able to iterate quickly, adjust quickly for changing user tastes, and adapt quickly to the ever-increasing pace of new technologies. To be able to do this effectively, instead of just developing fast, you need to be able to deploy quickly, react quickly, troubleshoot quickly, and update quickly. For many companies, this is no longer icing on the cake, but instead, the structure underpinning their business – in the same way that having an e-commerce site was 10 years ago.

Speed is becoming ever more critical for business in the digital age. With the rise of social media, a lot of customer feedback is public or semi-public, allowing people to unite behind specific complaints or desires and provide more clear and unified messages to companies. This helps companies get more feedback of higher quality and – hopefully – to react to it more quickly. This is also dramatically accelerating the cycle of getting features/products/releases to users, and, perhaps more significantly, prompting users to provide more useful feedback faster. As I mentioned, the scale and speed of business operations in every industry are growing daily, and, because of that, automation has gone from being beneficial to critical. In the technology world, this automation comes in the form of code.

Pushing your code faster and faster means you have to be able to update and deploy infrastructure faster, which in turn means infrastructure/systems teams must also be able to deploy, react, troubleshoot and fix faster.

But code, in and of itself, isn’t necessarily sufficient to meet the challenge of escalating speed and scale. How quickly you deliver that code is what’s important. Continuous Delivery is one technique used to address this need.

Continuous Delivery (CD)

People talk a lot about CD and it’s important to remember that this phrase refers to a methodology that has pros and cons.

For most technology companies, especially those whose product is primarily Web-based, CD is often the best choice to enable speed of delivery. The main benefit is that the closer to “continuous” your release-cycle gets, the easier it is to have an iterative process. Faster feedback from users means you can more rapidly deliver updates based on that feedback. As you approach CD, you approach near-real-time feedback, which allows you to hone your product or feature far faster than if it were sitting in long dev/qa cycles. Another benefit is best described with a comparison. In troubleshooting, a key rule is make one change at a time, so you know which change fixed the problem – or made it worse. CD is an extension of this idea, although it comes earlier in the lifecycle. If you are pushing/delivering a codebase more often, there are less changes per push, and so breakages are easier to track down – and it’s easier to push fixes.

A common misconception is that an organization either achieves CD or it does not. CD is a spectrum with frequent releases on one end and less frequent on the other. A CD solution for a bank may mean something very different than a CD solution for a gaming Web site. The idea of the CD methodology is continuing to push toward faster deployments, in order to reap the benefits that come from doing so.

In the end, no matter what part of the CD spectrum a company aims to achieve, they must be willing to adapt and change.

From an internal IT perspective, this means realizing that this isn’t the old world, where businesses lock users into small boxes to make things simpler. We’re in a world where everyone has the power of the Internet in his or her pocket and there’s enough information out there for anyone to break out of his or her box. Businesses need to provide engineers, designers, assistants, VPs, etc. the flexibility and freedom to work and think in ways they do best, so they can take the business to the next level.

From an external (production) IT perspective, companies must be able to quickly adapt to new growth and new technology. It took the Internet a (relatively) long time to start adapting to the small displays on mobile devices, and it adapted only slightly faster to tablets. But new form-factors are just the beginning. Broadband is becoming ubiquitous in first-world countries, and companies are just starting to rely on that fact. Yet there are still many users the Web isn’t taking into account very well. Mobile is becoming the default interface for a variety of locales and ages, and many countries have limited bandwidth and/or high latency. Further, it seems likely that we will see drastically different user input mechanisms, as well as display mechanisms, in the near future.

Technologists need to be agile and readily adapt to technology and infrastructure changes, as well as speed and approach changes, such as CD, which will be required for the next generation of user and technology demands.

About the author

Phil Dibowitz has been working in systems engineering for 12 years and is currently a production engineer at Facebook. Initially, he worked on the traffic infrastructure team, automating load balancer configuration management, as well as designing and building the production IPv6 infrastructure. He now leads the team responsible for rebuilding the configuration management system from the ground up. Prior to Facebook, he worked at Google, where he managed the large Gmail environment, and at Ticketmaster, where he co-authored and open sourced a configuration management tool called Spine. He also contributes to, and maintains, various open source projects and has spoken at conferences and LUG’s on a variety of topics from Path MTU Discovery to X509.

May 8, 2014