devopsy.kinsta.cloud

Category: Blogs

7,600 Open Source Projects Per Company (and how it impacts DevOps)

That Supplier is Better For You

Since releasing the 2015 State of the Software Supply Chain Report, there has been a lot of great discussion across the industry on best practices for managing the complexity introduced by the volume and velocity of the components used across your software supply chain.

Today I want to focus on the huge ecosystem of open source projects (“suppliers”) that feed a steady stream of innovative components into our software supply chains. In the Java ecosystem alone, there are now over 108,000 suppliers of open source components. Across all component types available to developers (e.g., RubyGems, NuGet, npm, Bower, PyPI, etc.), estimates now reach over 650,000 suppliers of open source projects.

Source: ModuleCounts.com

However, like in traditional manufacturing, not all suppliers deliver parts of comparable quality and integrity. My latest research, the 2015 State of the Software Supply Chain Report, shows that some open source projects use restrictive licenses and vulnerable sub-components, while other projects are far more diligent at updating the overall quality of their components. Choosing the best and fewest suppliers can improve the quality and integrity of the applications we deliver to our customers.

While I am hosting a webinar next week to share many of the detailed report findings, I wanted to share a few of the more meaningful stats here.

Your 7,600 Suppliers

My research for the report revealed many new perspectives on “suppliers” across the software supply chains. First of all, I saw that the average large development organization consumed over 240,000 open source components last year — sourced from over 7,600 open source projects.

Average number of open source component downloads per organization in calendar 2014

On the surface, the huge reliance on open source projects is a great thing. Development teams have chosen to not write those pieces themselves, but have sourced the needed components from outside suppliers. This practice speeds development, enables more innovation, and ensures time-to-release goals are achieved. The use of open source is so prolific today, few of us could ever imagine reducing the use of those components and their suppliers in the future.

At the same time that we benefit from open source, our high paced, high volume consumption practices don’t allow us the time needed to do the due diligence on the suppliers or open source projects where we source our component parts from.

Average number of known vulnerabilities downloaded by organization in calendar 2014.

For example, of the 240,000 average component downloads in 2014, the same businesses sourced an average of 15,000 components that included known security vulnerabilities. In many cases, developers were downloading vulnerable component versions, when safer versions of those same components were available from the open source projects. While no one intends to download components with known vulnerabilities, the problem is exacerbated due to the lack the visibility into a better recommended version.

Fewer Suppliers, Less Context Switching

Choosing an open source project supplier should be considered an important strategic decision in organizations because changing a supplier (“open source project”) used is far more effort than swapping out a specific component. Like traditional suppliers, open source projects have good and bad practices impacting the overall quality of their component parts.

Traditional manufacturing supply chains intentionally select specific parts from approved suppliers. They also rely on formalized sourcing and procurement practices. This practice also focuses the organization on using the best and fewest suppliers — an effort that improves quality, reduces context switching, and also accelerates mean time to repair when defects are discovered. One industry example from the report describes how Toyota manages 125 suppliers for their Prius to help sustain competitive advantages over GM who manages over 800 suppliers for the Chevy Volt.

By contrast, development teams working with software supply chains often rely on an unchecked variety of supply, where each developer or development team can make their own sourcing and procurement decisions. The effort of managing over 7,600 suppliers introduces a drag on development and is contrary to their need to develop faster as part of agile, continuous delivery and devops practices.

Coming to Terms

When you come to terms with the volume of consumption and the massive ecosystem of suppliers you can source your components from, you quickly realize it is impossible to address this issue with a manual review process. Any organizations clutching to these outdated manual practices are will continue to be outgunned by the velocity by their software supply chains.

Just as traditional manufacturing supply chains have turned to automation, software development teams need to take the same approach by further automating their software supply chains. Information about suppliers and the quality of their projects needs to be made available to developers at the time they are selecting components. Information about the latest versions, features, licenses, known vulnerabilities, popularity of versions being used, and the cadence of new releases should be made available to developers in an automated way. Automating the availability of this information about suppliers can lead to better and fewer suppliers being used.

Be sure to read the full 2015 State of the Software Supply Chain Report for more information about open source suppliers and organizations sourcing practices. The report also highlights current and best practices being used in organizations that are managing their use of suppliers that feed their software supply chains.

To hear more about the overall report findings and industry best practices, please join me on Wednesday, June 24th (1pm ET) for our webinar.

June 19, 2015
ProfitBricks shakes things up with new Docker hosting platform

Organizations and developers that want to leverage Docker containers have a variety of cloud platforms to choose from. Rackspace, Amazon, Azure and others all support Docker containers. There’s also a relative newcomer in the mix looking to shake things up.

ProfitBricks is an infrastructure-as-a-service (IaaS) company that believes it has a unique value proposition for companies that want to take advantage of cloud infrastructures and Docker container technology. ProfitBricks was co-founded by its CEO, Achim Weiss, and its CMO, Andreas Gauger. The two previously founded the Web hosting service 1&1 Internet.

Weiss and Gauger launched ProfitBricks four years ago to solve a perceived problem. They saw the value of cloud infrastructure and cloud services, but felt that the existing platforms suffered in the areas of performance, flexibility, usability and cost. So ProfitBricks was born.

ProfitBricks claims to have more speed and provide better value compared with rival cloud platforms. It calls its platform Cloud Computing 2.0.

ProfitBricks Docker Hosting

Docker has become a household name virtually overnight—quickly establishing itself as the de facto standard for container technology. David Bartletti, a principal analyst for Forrester, recently wrote in a research report, “Docker helps developers package code for quick assembly and hand-off to quality assurance, testing, and production release teams with greater confidence that their app will run consistently as it moves through the release process…The Docker open source community is growing quickly, with strong representation from nearly every major cloud vendor…As Docker containers proliferate, developers and operations teams alike will demand management tools that help organize and orchestrate hundreds or thousands of containers.”

With so much momentum behind Docker and container technologies, it makes sense for a cloud infrastructure provider to integrate Docker into its ecosystem. Last week ProfitBricks announced its new Docker hosting platform. The platform features dedicated resources, redundant block storage, and 80 Gbps networking. It allows developers to choose images, link containers, and expose ports. The free tier offers customers 2,500 CPU Core hours as part of the Early Access Preview with up to 4 CPU cores, 8 GB of RAM, and 100 GB of storage.

“When we first embarked on our Docker product architecture, we knew that it would not only need to meet the standards of existing Docker platforms, but also incorporate new, industry-leading features that addressed existing problems encountered with Docker,” said Achim Weiss, co-founder and CEO of ProfitBricks, in a press release. “Docker has been taking the DevOps world by storm since its widespread introduction to the community in 2014, and our platform will combine its impressive features with our flexible and painless cloud computing infrastructure.”

ProfitBricks says that one thing that sets its Docker hosting apart from the competition is autoscaling. The ProfitBricks cloud infrastructure will ensure that resources are automatically managed to meet the demands of the Docker containers running on it. Developers don’t need to rely on standalone applications or custom scripts to scale resources because those capabilities are integrated seamlessly into ProfitBricks.

ProfitBricks claims to be the best value in cloud computing. It offers a bold promise for the price / performance ratio on its site. “We guarantee that any workload deployed on ProfitBricks will cost less than the same workload running at the same performance level on the IaaS platforms of Amazon, Google or Microsoft.”

You can check out the new ProfitBricks Docker Hosting for yourself. Visit this link for an Early Access Invite and find out if ProfitBricks can really deliver.

June 11, 2015
5 Ways Continuous Integration Reduces Risk in Development

***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

There’s a lot of talk about DevOps and Continuous Integration in the tech space right now, but sometimes the implementation of those methods can be tricky.

An effective Continuous Integration strategy requires DevOps teams to manage risks in software development with a range of practices.

Here are five processes you can use to make Continuous Integration work for you.

Automated and Self-Testable Builds

DevOps professionals can use separate machines for software integration to eliminate the tight coupling between the build process and Integrated Development Environment (IDE) that leads to last-minute integration concerns.

Everything needed to build the software should be contained in a separate version control repository.

Dedicated Continuous Integration servers and open source build automation tools can run these builds through continuous testing processes and deploy the product in the required environments.

Automated deployment further eliminates the bottleneck of waiting for other team members to deploy testable versions of the latest software.

Synchronize Version Control Repository

Continuous integration is only possible as long as Dev, Ops, QA and the wider IT team is tightly integrated, collaborative and supportive of each other’s efforts.

From a tooling perspective, effective collaboration requires a separate-but-unified master database updating changes in real-time.

All database artifacts — including scripts, procedures and other assets should be placed in this version control repository.

DevOps teams can enable Continuous Database Integration by using automated database integration, local database sandbox and version control repository to share database assets, as well as empowering developers with capabilities to modify the database and making DBAs a part of the Dev team.

Build a Stronger Foundation and Expand Test Coverage

Limiting test cases to individual assets executed at every check-in to the version control repository ensures the continuously integrated builds are defect-free in combined form.

Tests should be repeatable and performed continuously in virtualized systems replicating unavailable testing environments.

Continuous Integration methodologies allow you to determine how much of the code was actually tested without much manual intervention.

Although some code coverage tools can assess the percentage of test coverage by package or class, Continuous Integration systems ensure this coverage is updated in real-time.

For instance, DevOps teams can run these tools as part of the Continuous Integration server build script every time the version control repository is updated with a code change.

With this information, untested code would never get through to the next stage and the latest test will be conducted across all areas as required.

Enhance Project Visibility

With automated build testing and deployment using a centralized code repository, build feedback mechanisms update Devs and Ops with the latest test results and the necessary progress information.

In cases when the same level of automation for complex builds seems impractical, DevOps teams using manual procedures must establish a feedback loop to bring everyone on the same page with real-time communication and notification of accurate performance and results.

These capabilities ensure the same high standard of reporting is maintained for manual testing practices as available for automated build testing systems.

Follow Consistent Dev Standards

Quality code forms from the ground up, with adherence to common code and architectural standards established for an organization’s specific requirements.

Automated inspection tools enable Devs working on short and quick builds to maintain their focus on quality from the very foundation of the software itself.

DevOps teams should assess every integration build for potential defects that surface after integrating several iterative builds but should be taken care of far earlier during the development stages.

In Conclusion

The right toolset is key to Continuous Integration, as is the cultural change that facilitates this DevOps practice.

Continuous Testing presents several areas of improvement for DevOps teams to develop iterative builds in individual, isolated branches and then merge the latest builds in a unified, single and well-synchronized Master branch.

The idea is to ensure all risks are mitigated beforehand so DevOps professionals are not bogged down with endless needs to rework the product — and that gives them time to focus on true Continuous Integration.

June 9, 2015
Top 3 DevOps Practices for Operational Stability

Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.

(more…)

June 4, 2015
Continuous Testing: What exactly is it?
***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

The aptly named DevOps practice of Continuous Testing synchronizes Testing/QA with Dev and Ops processes optimized to achieve business and development goals.

A few years ago when Agile was all the rage, lightning-fast Dev sprints left the Ops and QA personnel playing catch-up due to inadequate and sluggish testing practices with minimal coverage across frequent builds.

The widespread culture of Agile development has accelerated development while software testing still lags behind, forcing organizations to cut corners in QA or slow down Dev processes entirely.

Instead of speeding up the conveyor belt beyond control or slowing down development to kill efficiencies, Continuous Testing in DevOps encourages a systematic approach toward process improvement.

Continuous Testing goes beyond automation and encompasses all practices — including tooling and cultural change — that help mitigate risks before progressing to subsequent Software Development Lifecycle stages.

Continuous testing and Automation

The approach to Continuous Testing can vary and follow diverse pathways to ensure the best user experience is delivered, free of defects.

It’s barely viable to repeat all tests every time a new feature is added, so the Continuous Testing strategy fosters a company-wide cultural change to achieve four capabilities: Test early, test faster, test often and automate.

End-to-end test automation practices are intended to integrate QA into existing fast-paced Dev and Ops processes as a means to create continuity while maintaining faster development cycles.

It’s important to understand the role of automation in Continuous Testing. Automation alone does not enable continuity in testing, but it helps provide a qualitative assessment of risk and practice actionable tasks to mitigate these risks throughout the SDLC.

In essence, automated testing constitutes the detection process for software issues and defect prevention, whereas Continuous Testing addresses the wider challenge of improving the effectiveness of these detection sensors.

What does Continuous Testing Look Like

This example demonstrates how collaboration, automation and tooling enable end-to-end testing that’s performed faster, more often and better aligned with Agile Dev and Ops practices.

Continuous Testing starts within development processes as Devs use open source tools such as Selenium to test the functionality of their code.

Tools such as GitHub or other internal repositories can then be used to store tests and version together with the software code. DevOps teams can use the same tests to integrate frequent builds of the software with the Load Impact API.

Once the code reaches preproduction, dedicated QA teams can use these tests by modifying dynamic test parameters as appropriate. In the production environment, Ops can reuse these tests for acceptance testing and ongoing post production monitoring.

Once the application goes live, integration with existing APM tools help keep tabs on server-side app metrics.

Continuous Testing in this example is broken up into at least four environments: Development environment, Continuous Integration environment, QA Pre-production and Performance testing environment, and the Staging environment. Additional post-live monitoring further enable end-to-end continuous testing.

Key Elements of Continuous Testing

Parasoft, a global software solutions company, is one of the great thought leaders in DevOps and Continuous Testing. The company has laid out some key elements of the process in a fantastic e-book, and they’re definitely worth sharing here:

Risk Assessment: Covers risk mitigation tasks, technical debt, quality assessment and test coverage optimization to ensure the build is ready to progress toward next SDLC stage.

Policy Analysis: Ensure all processes align with the organization’s evolving business and compliance demands. Primary objectives include:
- Identifying trends associated with injection of dangerous patterns within the code
- Augmenting defect prevention practices for high risk areas
- Isolating risk in target areas
Requirements Traceability: Ensure true requirements are met and rework is not required. An object assessment to identify which requirements are at risk, working as expected or require further validation.

Advanced Analysis: Using automation in areas such as static code analysis, change impact analysis and scope assessment/prioritization to prevent defects in the first place and accomplishing more within each iteration.

Test Optimization: Ensure tests yield accurate outcomes and provide actionable findings. Aspects include Test Data Management, Test Optimization Management and Test Maintenance.

Service Virtualization: Early, frequent and everywhere testing requires access to real-world testing environments. Service visualization enables access to the virtual form of the required testing stages, cutting the waste time to test environment setup and availability.

An effective Continuous Testing strategy incorporates all of these elements and forces an organization-wide cultural change to synchronize Dev, Ops and QA/Testing as part of the true DevOps philosophy.
May 27, 2015
Moving from Infrastructure Automation to True DevOps

Deciding on two separate teams, or an integrated end-to-end team

While a lot has been said about “the right way” to do DevOps, what we’re seeing in practice are two different approaches being tried to enable development and operations to work together as a team. On the one hand, there’s the approach to create an end-to-end, integrated development team, which you might call ‘Devops’. On the other, there’s ‘DevOps’, featuring two development teams – one working on application code, with another developing a platform using Infrastructure as Code techniques in a virtualized environment.

DevOps: providing a platform

Perhaps the most obvious way to go is to have a platform team to provide a runtime environment that “just works”, and a separate application team that develops the business logic to run on the platform.

For some organizations, particularly where one of the teams is outsourced, this separation is going to make more sense. You might buy an off-the-shelf product, build your own platform in-house (which seems to be what many organizations are looking to do with Docker right now – warning: it’s harder than it looks!) … or sign up with a PaaS vendor.

Whatever the situation, the platform should be versioned, just like any other piece of software.

This approach can be ideal for developers because they are free to work on code and focus on the business logic, and they really don’t need to worry about how it runs in production. It’s up to the operations team to make sure that the platform is stable and that it delivers what the developers need.

Communication is still key

Even with a physical or organizational separation, the importance of effective dialogue between the two teams cannot be overstated. This won’t work if the relationship is adversarial. There has to be a genuine awareness of common goals. If the operations team doesn’t understand where the development team is going, and what they need from the platform, then there’s going to be trouble. The idea that one platform is going to cater for every development need is often unrealistic, so versioning and the ability to run multiple platform versions side-by-side, or cater for exceptional situations where a particular application might need its own stack, is very important.

There has to be a clearly defined boundary, which should be close to the application code and configuration layer. The application handles the business logic, the platform handles the deployment, logging, monitoring, failover and auto-scaling.

The development team can focus on getting those new features and improvements into the live product, while operations handles the actual roll-out and manages traffic. For this to work, the platform must enable you to quickly determine who is responsible for any problem that crops up. It’s worth investing time in the setup to ensure that errors are explicit, so you don’t waste time tracking them down.

Arguments between the two teams are bad for progress and morale.

Devops: A full stack development team

For some businesses, it’s going to make more sense to put together integrated development teams that work directly on delivering the full stack from a shared code base, from virtual machine to application code. This allows you to design and optimize each system in a way that takes the application’s specific perspective and requirement into account, and can be an especially good fit if your applications differ from each other greatly in terms of the operating systems, middleware, etc., that they run on.

This approach can only work if the overall group is small (Amazon’s “two pizza” teams are a good example) and has sufficient knowledge and experience to see the big picture of the entire system.

It’s not possible for everyone to understand every part of the full stack in detail, but there are areas of overlap where greater collaboration will increase the level of shared knowledge and allow the team to build a better overall system.

Pulling together

The shared foundation of the Devops approach builds mutual respect and enables more free-flowing communication, but it must be based on shared goals and a vision of what the overall purpose of the system is. This integrated approach can give you much more flexibility, but it also means holding the whole team responsible for keeping everything running. Shared code equals shared responsibility.

The right approach

You need to take a baseline, and then put metrics in place to track your progress. You have clear goals in mind and a system to measure them. So how do you find the right approach to achieve those goals?

It would be wrong to say that one approach is better than the other. What you need to do is assess what will work in your organization. Both are means to achieving similar goals, but finding the right approach is about understanding what your company is looking to achieve. You might choose common goals, like reduced expenditure, or reduced error, or you might choose something more specific to your industry. Establish your goals at the outset, and make sure that they’re measurable.

The right approach is going to be the one that gets results for you — that’s why setting up a baseline and metrics is so important. You may find that a hybrid of the two approaches is going to be the right fit, but you aren’t going to know for sure until you have some hard data to back up your expectations.

Be sure to join DevOps.com editor-in-chief Alan Shimel on Thursday, May 21^st as he hosts the webinar, “Ship Faster without Breaking Everything” to further your smarts on Continuous Delivery.

About the Author/Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

May 14, 2015
Hyper-V Containers combine virtualization with containerization

Containers are all the rage these days. You’re just not cool if you’re not using Docker or some other container technology to build and deploy your IT infrastructure. Traditional containers, however, lack sufficient security for some industries and companies, so Microsoft developed Hyper-V Containers.

Container platforms like Docker and Rocket have significant momentum and have quickly become established as a de facto way of developing and deploying applications. Microsoft already entered into an arrangement to bring native Docker container support to Windows Server, but now it is going a step farther by creating Hyper-V Containers that combine the agility of containers with the security of virtualization.

Hyper-V Containers ensure that code running in one container object remains completely isolated. The Hyper-V Container object cannot impact other container objects or the host operating system, or vice versa, because it is a separate virtualized container. Mike Neil, general manager of Windows Server for Microsoft, explained in a blog post, “Leveraging our deep virtualization experience, Microsoft will now offer containers with a new level of isolation previously reserved only for fully dedicated physical or virtual machines, while maintaining an agile and efficient experience with full Docker cross-platform integration.”

IT admins will appreciate the fact that Hyper-V Containers can be created and deployed using the same development and management tools used for traditional Windows Server Containers and that they integrate with Docker for cross-platform deployment. Neil points out that applications developed as Windows Server Containers can easily be deployed as Hyper-V Containers without any modification—enabling organizations to take existing containerized apps and re-deploy them in a more secure manner.

It seems like security is always an afterthought to any new technology concept, and containers is no exception. It started out as a good idea that caught fire, but it wasn’t until it hit critical mass and achieved mainstream adoption that security became a factor. As larger companies, or organizations in highly-regulated industries look at jumping on the container bandwagon, though, security becomes a mandatory component.

Virtualization has been used in hosted environments for years as a means of isolating different systems running on the same physical hardware or network. Microsoft’s Hyper-V Containers take those same principles and apply them at the container app level so that security-conscious organizations can have some peace of mind and remain compliant with security mandates as they embrace containerization.

Microsoft’s strategy of integrating Windows Server Containers and native Docker support in Windows Server and Azure was a big step in the right direction. Adding the security of Hyper-V Containers is brilliant. Microsoft is doing an excellent job of pivoting its business model and not just embracing cloud and DevOps technologies, but raising the bar and taking the lead.

As a side note Microsoft also announced Nano Server—a new minimal footprint implementation of Windows Server optimized for cloud hosting and container technologies. The Nano Server installation includes the bare minimum components necessary. Microsoft claims the result is smaller server images, faster deployment times, decreased network bandwidth consumption, and reduced administrative overhead. In other words a Nano Server installation of Windows Server will just do what it’s supposed to do with minimal interaction or oversight so IT personnel can focus on more important things like the Hyper-V Container apps running on it.

April 13, 2015
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
Webinar: How Nationwide Insurance is Adopting DevOps for Variable Speed IT Systems

To drive towards faster innovation, and also ensure the stability of the core business, the need arises for what is being termed as “two-speed or variable speed IT.” While innovative Systems of Engagement demand speed, agility and experimentation, legacy Systems of Record need governance and predictability. Two-speed IT enables adoption of DevOps capabilities by adapting them to the “speed” of delivery. It requires two-speed business planning and processes and even two-speed organizational structure and budgeting. Join Carmen DeArdo, Director of Application Development at Nationwide Insurance, Sanjeev Sharma, lead DevOps Technical Evangelist at IBM, and Lee Reid, executive IT specialist as they show how IBM’s solution is helping Nationwide adopt DevOps practices for variable speed IT systems.

This webinar is the first in the Variable Speed DevOps – A Deep Dive series.

Event recorded Tuesday May 5th, 2015

SLIDES

[seoslides embed_id=”be17733a1254″ script_src=”https://devopsy.kinsta.cloud/embed-script/webinar-how-nationwide-insurance-is-adopting-devops-for-variable-speed-it-systems/6643/” overview_src=”https://devopsy.kinsta.cloud/slides/webinar-how-nationwide-insurance-is-adopting-devops-for-variable-speed-it-systems/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Webinar: How Nationwide Insurance is Adopting DevOps for Variable-Speed IT Systems” /]

VIDEO

Your Host:

Alan Shimel, Editor-in-Chief DevOps.com, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Carmen DeArdo, Nationwide – Director – Tools and Technology Leader

Carmen DeArdo, Director – Tools and Technology Leader, Nationwide Insurance, An ardent advocate of DevOps and a leading speaker in the DevOps and technology related events, Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies.

Sanjeev Sharma, IBM Worldwide Lead – DevOps Technical
Sales and Adoption, IBM Cloud Unit

Sanjeev Sharma, IBM Worldwide Lead – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.

Lee Reid, IBM – Senior IT Specialist

Lee Reid, Senior IT Specialist, IBM, is a senior solution architect with focus on practical adoption of software engineering tools, software delivery solutions, application life cycle management, and DevOps. He has over 25 years of experience in software engineering, design, programming, testing, development, tools & methodology, team leadership, and strategic planning.

March 31, 2015
Continuous Documentation

Is documentation dead in DevOps? Yes and no. It is transformed, it is automatic, and it is actionable.

(more…)

March 30, 2015