Welcome!

@DevOpsSummit Authors: Liz McMillan, Pat Romanski, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui

Related Topics: @DevOpsSummit, Java IoT, @CloudExpo

@DevOpsSummit: Blog Feed Post

What Infrastructure Should Learn from NPM JavaScript Debacle By @LMacVittie | @DevOpsSummit #DevOps

We can learn a lot from the development organization about how to best go about transitioning to an approach like DevOps

If you hadn’t seen (and you might not have, it was a developer kind of thing after all) there was a big uproar caused by the removal of 11 lines of JavaScript from the popular NPM repository. You can read more about it but the TL;DR is this: dude removed some JavaScript that was relied on by thousands of other projects and basically broke them all. Because those projects not only relied on that code, but relied on code stored in an online repository.

Now before we go further, I have to say that despite the millions (yes, millions) of projects that rely on JavaScript and CSS stored in web-hosted repositories, this is one of the first incidences of something like this happening. And there’s a lot more to this story than just the ramifications. But as I’m not a lawyer (and don’t play one on the Internet nor did I stay at a Holiday Inn Express last night) I’m just going to focus on the impact rather than who is right/wrong/etc… After all, you probably don’t go more than an hour without loading a web app that in turn loads a script from Yahoo or Google or some other online repository so the discussion is really about how relying on online repositories can really mess up your day.

learnWhile this story really hits developers hardest right now, in the future this is something that could impact networkers, so we should talk about it now, rather than in some future post mortem blog.

If we’re going to treat infrastructure as code (and perhaps critical infrastructure, at that) then we need to carefully consider where we’re going to manage the artifacts (templates, scripts, etc…) that make up the metastructure of our modern, automated infrastructure architecture.

First and foremost, we shouldn’t store these on individual creators laptops. Really, if Bob has the most current version of the “deploy critical app A” script and something happens to his system, you’re hosed. If Alice has been vigilantly maintaining the base corporate  security template and malware or an inadvertently hit “delete” key gets rid of it, what do you do? There are a hundred and one different mishaps that could occur that suddenly halt the continuous deployment of an application.

Developers learned that lesson long ago. And to avoid that they moved to network-hosted repositories. Most of them include (or are) version control systems with extra layers of authentication and authorization around them to ensure that only those people (and systems) that should have access, do have access. These are, because of the very nature of storing the corporate secret sauce (application code), usually on-premises. They are replicated, backed-up, and treated with the importance they deserve.

At some point developers started directly grabbing scripts and stylesheets and other dependencies from the web. UI elements and frameworks were automatically included in web apps and downloaded in real time from the web. This had the advantage of making sure they were always up to date. It’s like automagical updates and patching, no work required. And it was good, until one piece of the web was suddenly inaccessible (rarely happens, but it does).

This is much like what recently happened with NPM. A whole lot of other projects depended on one smaller project that was loaded from the web in real time. And when it disappeared, wham! Everything that depended on it being there broke.

If you browse around online repositories of DevOps frameworks like those that host Chef or Puppet fragments, you might find that a lot of them are hosted on Git. Git – and similar systems like Puppet Forge - offer everything you need (including a great API) that would let you pull, in real time, the latest and greatest versions of these infrastructure-related artifacts. Right into your CI/CD process. Cause you are extending that to your (network and app service) infrastructure, right?

This is where we need to stop, take a deep breath, and consider we might not want to do that directly.

Git – and similar systems – also offer local repository support, with the ability to synchronize with the “central” repository online. Yes, that means another piece of infrastructure you have to install, manage, and maintain locally, but if you consider that you’re not only worried about availability but also the potential for an update to “break” your process, you really want to think about this now, rather than later.

I wholly recommend the use of version controlled repositories as you’re embarking on this journey to transform the network (all of it) into a more agile and automated environment. Treating infrastructure as code can make roll-backs and replacements a whole lot easier to manage if the latest and greatest configurations can just be pulled out of a controlled repository. But that controlled repository should be just that: controlled. It should be local to the environment because otherwise it’s not controlled at all. Not really. Availability issues, unexpected changes, or outright removal of dependencies are a risk that should be considered well in advance of implementing the system.

One of the hardest cultural impacts that will be wrought on networking by shifting left (into the CI/CD process) will be the need to implement the kinds of controls and processes on changes to infrastructure as are currently expected on the app code itself. Code reviews, version control, and the use of repositories will be mandatory in the future if we’re to actually treat infrastructure as code. That’s a marked difference from right now, where scripts and artifacts may or may not be required to submit to a review / approval process, and where the latest artifacts are often stored “on that server” or “on Bob’s laptop.”

The good news is that developers have suffered through this journey already. We can learn a lot from the development organization about how to best go about transitioning to an approach like DevOps that treats infrastructure as code. Don’t let their lessons go to waste.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@DevOpsSummit Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
Discussions of cloud computing have evolved in recent years from a focus on specific types of cloud, to a world of hybrid cloud, and to a world dominated by the APIs that make today's multi-cloud environments and hybrid clouds possible. In this Power Panel at 17th Cloud Expo, moderated by Conference Chair Roger Strukhoff, panelists addressed the importance of customers being able to use the specific technologies they need, through environments and ecosystems that expose their APIs to make true change and transformation possible.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and GM, discussed how clients in this new era of innovation can apply data, technology, plus human ingenuity to springboard to advance new business value and opportunities.
DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. IoT Now explores the evolving opportunities and challenges facing CSPs, and it passes on some lessons learned from those who have taken the first steps in next-gen IoT services.
The current age of digital transformation means that IT organizations must adapt their toolset to cover all digital experiences, beyond just the end users’. Today’s businesses can no longer focus solely on the digital interactions they manage with employees or customers; they must now contend with non-traditional factors. Whether it's the power of brand to make or break a company, the need to monitor across all locations 24/7, or the ability to proactively resolve issues, companies must adapt to the new world.