devopsy.kinsta.cloud

Category: Features

  • Microsoft and GitHub: The Sky is Not Falling

    Microsoft and GitHub: The Sky is Not Falling

    The consternation seen in some corners of the internet over Microsoft’s agreement to acquire GitHub is overblown and too early.

    For those who don’t follow me normally, I am a developer for Windows, Android and Linux. I am also a user of both GitHub and BitBucket. While I am an advocate, I am more of an IT productivity/tools advocate than a pro/con MS advocate. So pretty much, I am IT. I’ve worked in pretty much every IT environment from developing embedded devices to cell phones to apps for smartphones to a raft of enterprises from financials to utilities.

    Until we know what Microsoft intends with GitHub, it makes no sense to go crazy with plans to migrate away from the platform.

    Oh, I could draw up plans to move my company’s GitHub repositories to BitBucket (or GitLab, or wherever), but honestly at this point there is no reason to do so. We (all of IT) have a limited amount of time available, and is migration away from GitHub the best use of that time?

    I argue that at this point, it absolutely is not.

    Stop. Breathe.

    There are things Microsoft could do that would make my company want to move away from GitHub. I do not expect that any of those things will happen. Or if they do happen, it is because they were going to happen anyway.

    Remember, early rumors of this merger started with, “They were working on joint marketing, and GitHub let slip they needed a cash infusion …” needed a cash infusion. That means something at GitHub needed to change regardless of ownership. You don’t go as long and get as large as it has and need a cash infusion, if you’re doing things right. So change was likely coming, regardless of ownership.

    But until we see what Microsoft has planned, expending energy either complaining about it or planning to move away seems like a bad use of your time. As long as git pull still works, and the terms of service haven’t changed, it is much ado about nothing.

    Stay focused on your customers, and keep a wary eye on developments with regards to all of your back-end tools, but don’t waste energy in potentially unnecessary or fruitless exercises. Think about it, and if it becomes necessary, we can all make careful, planned moves when it’s clear that is the proper course.

    — Don Macvittie

  • How DevOps Replaces the BYOD Mindset

    How DevOps Replaces the BYOD Mindset

    The impasse is clear: users often have no formal way to effectively communicate to IT departments how certain devices and apps are useful for work and should be allowed to connect to the enterprise’s network. Since the debut of smart phones well over a decade ago, so-called bring-your-own-device (BYOD) policies as a potential solution have served as a solution, but have also fallen short for reasons we’ll discuss below. The idea behind BYOD is to allow users to connect their devices in limited circumstances and often without full access to the network.

    BYOD also predates DevOps and serves as one of many precursors for IT and security working more closely with other teams within the organization. This mindset of collaboration that BYOD fosters, of course, is essential to DevOps, said Holger Mueller, an analyst for Constellation Research.

    “The tension between the business and IT really is about scaling an organization’s operations in a way that is both flexible and business-focused,” Mueller said. “Compromise really matters.”

    However, DevOps, in part, can remove the need for BYOD and even replace it from IT jargon. BYOD first came about when IT, operating in isolated silos, struggled with accommodating users who used their own devices for work and, even more worrisome, often connected their devices to the network without permission. This worry is eliminated with DevOps when business, IT operations, QA, InfoSec and development teams, in the spirit of fostering collaboration across the enterprise, decide together what devices and apps are adopted, and then lay the security groundwork.

    “With the advent of more agile and distributed infrastructures, DevOps teams don’t have a walled-garden assumption anymore, which makes BYOD less of a problem in general,” said Siri Oaklander, advanced technologies principal for CloudPassage. “When BYOD started, the concern was these devices represented an unknown inside the corporate walled garden, and now we are not depending on the walled garden nearly as much for security.”

    New Mindset

    Enabling users to bring new devices and apps into the network certainly falls under the culture part of DevOps. Someone in DevOps who is a business team leader might suggest a very useful app or platform the IT department, the developers, and InfoSec readily review and test because it makes good business sense. Again, this type of interdepartmental collaboration is difficult without DevOps.

    For organizations without DevOps, suggested changes from users requesting the IT department accommodate new devices and apps, even when BYOD policies are in place, are often met with hostility, since it means more work with little perceived direct gain for an isolated IT department. Those working in IT, in this context, thus have little motivation to do the legwork to make room for new devices to manage. DevOps, of course, helps to change this mindset.

    “DevOps-style security  completely changes the boundaries and gateways, eliminating a lot of the concerns associated with BYOD,” Oaklander said. “It’s not so much that DevOps directly addresses BYOD as that the security model used in DevOps is far less vulnerable to having unmanaged devices inside the network.”

    Bring-Your-Own-IaaS

    BYOD came into play before the emergence of massive cloud deployments and the monumental shift many organizations have made to the cloud. Then, operations were often exclusively tied to the data center. Smart phones and other devices, once behind the firewall, were connected to the network that ran on on-premises servers. These servers, as well as virtual machines, were the core parts of the business and often mission-critical, noted Ed Smith, product marketing principal, for CloudPassage.

    “Now DevOps teams no longer have to rely on IT for servers either, they simply go to AWS with their credit card and bring their own infrastructure as a service,” he said. “The similar challenges apply here as they did with BYOD: How does the company control cost and risk without slowing down innovation? And there’s more at stake here because these are back-end servers used by many people as opposed to a device with a single user. BYOD happened because business users demanded it to be agile and competitive, and I think we’re seeing the same thing with what may be called ‘BYOIaaS.’”

    DevOps should thus be ready to take advantage of new cloud solutions, as well as cloud-exclusive applications, in ways BYOD would never have allowed.

    — B. Cameron Gain

  • Microsoft Is Acquiring GitHub for $7.5B, Becomes Steward of Leading Open Source Repository

    Microsoft Is Acquiring GitHub for $7.5B, Becomes Steward of Leading Open Source Repository

    As part of its effort to get even closer to the developer community, Microsoft is acquiring GitHub for $7.5 billion. GitHub controls the open source repository that is at the center of millions of DevOps processes and is home to up to 28 million developers worldwide.

    Microsoft CEO Satya Nadella said GitHub will remain an open platform that developers will be able to employ for any programming language to deploy software anywhere. As part of that commitment, GitHub will continue to operate as a Microsoft business unit led by Microsoft Corporate Vice President Nat Friedman, founder of Xamarin who will assume the role of GitHub CEO. Current GitHub CEO, Chris Wanstrath, will become a Microsoft technical fellow, reporting to Executive Vice President Scott Guthrie. Wanstrath previously announced his intention to step down as the CEO of GitHub. The deal is expected to close before the end of this calendar year.

    Nadella said Microsoft is committed to acting as a steward for GitHub rather than making the open source repository an element of the application development business unit.

    Microsoft recognizes that GitHub is the platform through which millions of developers now collaborate, said Nadella. Acquiring GitHub presents the company with an opportunity to get closer to the developer community by providing both the platform they collaborate on as well as the tools many of them rely on to build applications. That’s critical now because as more organizations transform into software companies, those organizations are pouring more resources into application development and workflows than ever, Nadella said.

    Friedman said GitHub will focus on making it easier for cloud service providers to plug their platforms into GitHub, adding Microsoft is also committing to making all its application development tools available on the GitHub marketplace. The company also will make GitHub services available via its direct sales and reseller channel.

    It’s unclear yet how the open source community that relies on GitHub will react to the stewardship of Microsoft. There are plenty of smaller repository options that might benefit from developers deciding to shift their allegiance. Microsoft clearly is aware of the potential downside, which helps account for why Friedman is stressing that any effort to make it simple to integrate GitHub with cloud services would apply to all services, not just Azure. At the same time, however, given its long history of delivering application development tools, there’s probably a deeper appreciation for how GitHub plays to a Microsoft customer base that counts developers as its largest segment.

    On the plus side, Microsoft will become a much bigger advocate for application development based on open source code. The company steadily has been making large swaths of its application development tools available as open source code. Less clear is to what degree it will be willing to embrace open source across its entire portfolio. With more than 2 million commits made to GitHub a year, Microsoft claims to be the largest contributor to GitHub.

    The challenge from a DevOps perspective, however, is not the repository employed to house code, but rather how well that repository fits into a larger continuous integration/continuous deployment (CI/CD) environment.

    — Mike Vizard

  • Microsoft Snaps Up GitHub for $7.5 Billion

    Microsoft Snaps Up GitHub for $7.5 Billion

    Recognizing the role GitHub plays in the larger developer and DevOps ecosystems, Microsoft is acquiring the software development platform for a cool $7.5 billion, the two companies have announced.

    GitHub, the world’s leading software development platform, has more than 28 million users who “learn, share and collaborate to create the future,” according to the press release announcing the acquisition.

    “Developers are the builders of this new era, writing the world’s code. And GitHub is their home,” wrote Microsoft CEO Satya Nadella in a blog post. He noted Microsoft is the most active organization on GitHub, with more than 2 million commits made to projects.

    “Microsoft has been a developer-focused company from the very first product we created to the platforms and tools we offer today. Building technology so that others can build technology is core to our mission to empower every person and every organization on the planet to achieve more,” he wrote.

    GitHub CEO Chris Wanstrath was quick to point out the irony of Microsoft, once a bastion of proprietary software and apps, purchasing a repository for open source code.

    “When GitHub first launched ten years ago, I could have never imagined this headline,” he wrote in his blog. “Git was a powerful but niche tool, clouds were just things in the sky, and Microsoft was a very different company. Open source and business, people said at the time, mixed as well as oil and water.”

    That said, there is a certain synergy between the two companies, he noted. “We both believe that software development needs to become easier, more accessible, more intelligent, and more open, so more people can become developers and existing developers can spend more time focusing on the unique problems they’re trying to solve.”

    Under the terms of the agreement, Microsoft will acquire GitHub for $7.5 billion in Microsoft stock. The acquisition is expected to close by the end of the calendar year.

    Keep checking devopsy.kinsta.cloud for updates on analysis on Microsoft’s purchase of GitHub and its potential impact on the DevOps community at large.

    — Charlene O’Hanlon

  • DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    Andrea Martinez, now Andrea Crawford, is the CTO for DevOps for IBM Hybrid Cloud. In this DevOps Chat we had a great discussion on what is “modern apps in DevOps,” how to upgrade your legacy apps, what to do if your legacy apps are not upgradeable and what this all means for DevOps.

    Great discussion and as usual, the streaming media audio of our conversation is immediately below, followed by a transcript of our conversation.

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. DevOps Chat today is going to be a good one. We have with us Andrea C. Martinez who is the CTO for DevOps for IBM’s hybrid cloud.

    Andrea, welcome to DevOps Chat.

    Andrea Martinez: Hey, thanks for having me, Alan.

    Shimel: Thank you. Did I get that all right?

    Martinez: So, I’m mostly known as Andrea C. Martinez but I’ve recently gotten married so my new last name is Andrea Crawford. Different last name but the same cowboy hat. So I always wear my cowboy hat in my profile pics. If you’ve got the hat you’ve got the right gal.

    Shimel: And it’s the right Andrea. Okay. No hyphen – Martinez-Crawford or something like that?

    Martinez: Nah, I’m not that fancy. It’s just Crawford.

    Shimel: I’ve got to tell you I just got back from China last week and I was with my partner Jayne Groll, one of the co-founders of the DevOps Institute, and one of my co-founders there, Jayne Groll, is actually now Jayne Groll-Ray because she’s also recently married and what a mess on the – hats off to you – getting your passports done and redone and what name to use because you know it has to match exactly and all your other IDs – I didn’t realize what a –

    Martinez: Alan, that’s why we get the diamonds in our ring.

    Shimel: I guess so. Yeah, and well-deserved. Anyway, congratulations on your recent marriage but we’re going to talk DevOps and we’re going to talk a little bit about modern applications here today, okay?

    Martinez: Awesome. Sounds good.

    Shimel: Great. All right. So I should mention that we have a webinar coming up on June 28 at 1 p.m. Eastern time on this topic and really this chat is just sort of a lead-in to the full hour-long webinar and that webinar is on DevOps for application modernization and we’ll put the link to it in our show notes here but if you find what we’re talking about today interesting by all means check out the webinar.

    But let’s dive in. So Andrea, let’s talk a little bit about modern applications versus non-modern applications: Do we have archaic applications, are they obsolete applications? What do we mean when we say a modern application?

    Martinez: Yeah, I think to – and by the way, I like your archaic reference there. I think to really appreciate the modern application we really have to understand how applications use to be designed and built not all that long ago.

    So, if I were to go back to the N-1 generation of applications I could make some pretty broad characterizations of how they were designed, built and delivered. So, if we were to like take it back to around the late-Clinton era of post-dot.com boom, world wide web and the internet, you know, that was really becoming the network platform where enterprises were exposing business function and really more of nascent digital economy.

    So some of the characteristics of what I’ll call “heritage applications” were, No. 1, they were monolithic so the applications lived on these things called “application servers,” typically running on maybe like higher end commodity infrastructure – think like X86, power hardware with large amounts of disk and memory, we had big centralized databases and these memory hog application servers.

    So the applications ran inside these app servers and they were fairly monolithic – that means they basically bundled the presentation or the view, the business logic and the data model components all together.

    The second characterization I would say for heritage applications is that they lived on these app servers that resided on these sort of heavyweight operating systems and although at the time Linux was very much on the scene overall. The trust in Linux was not yet solidified so you had these operating systems that were sort of these enterprise, server, big and bold editions of this OS – and it was pretty prevalent, you know? Windows and proprietary Unix based operating systems pretty much ruled the day.

    And, No. 3, the – in terms of the infrastructure on-premises data centers ruled the roost. I mean virtualization technology’s around, we had this notion of logical partitions, L-pars, VMware, virtualization, but it was mostly a hardware OS story, okay?

    And then we had, in terms of looking at the actual heritage applications themselves, we had the rise and dominance of function-rich languages like Java and dot-net because the application server middleware pretty much dictated the language of what an application was coded in, right? So we still have a lot of these skills around today.

    And I think the last characterization of a heritage app was in the way that they were delivered. So we had the waterfall delivery – very sequential, big-bang releases with siloed organizations, dev teams didn’t really talk to the operations teams and having that kind of silo was pretty much the norm.

    So, that’s how I would sort of characterize the heritage applications.

    Shimel: Yeah, dead on for me Andrea. We didn’t talk about this but in my background I had started a web hosting company in those dot-com days and I sold it to a company and started to work with them and we were one of the first big, what they called ASPs, if you remember those days – application service provider – and so this is – we wound up doing the whole IPO and all of that – this is 1997, ’98, ’99, 2000, into 2001 –

    Martinez: Absolutely. Yep.

    Shimel: Oh, they were glory days. We were probably one of the largest Lotus notes, if you – you know,

    Martinez: Yeah, all right.

    Shimel: So, picture this: We’re hosting – we are offering hosted Lotus notes as a service – it’s not even IBM WebSphere yet, I think it was still notes server –

    Martinez: Domino?

    Shimel: No, it wasn’t even Domino. What came before Domino? I mean this is old. And then Domino came out and it kind of rocked our world because it was really a big thing for us. But there’s no – it was on dedicated hardware, there was no cloud, T1 lines were about $1,200 a month, and so you had to deliver it over a T1 line oftentimes – you know, a dedicated T1 line point to point – and then we expanded to PeopleSoft and Oracle apps and stuff like that, and what a disaster. I’ve got to be honest. I mean we went through about $500 million – a half-a-billion dollars in monies raised between the IPO and so forth – but it was hard. It was really, really hard.

    And then we tried to get into the whole custom app kind of hosting with ISVs and so forth.

    Martinez: Oh boy.

    Shimel: So, what you just described I had a déjà vu to my bones and, yeah, I wouldn’t call those modern applications but I think we’ve done a good job.

    Now contrast that, though, with what modern applications are like today, Andrea.

    Martinez: Yeah. So there’s sort of been an inflection point where some pretty emergent things have happened since those days, right? And you know we dealt with all of those issues around the heritage environments and applications. And now all of the sudden if we take a look at what I call “modern applications” today – Alan, you mentioned the cloud – No. 1, modern applications live in the cloud. So these applications leverage the elastic, infrastructure and platform that comes with it.

    When we develop modern applications – you also may have heard them referred to as “cloud-native applications” or “born-on-the-cloud applications” – and really what has happened here is to leverage that type of virtualized infrastructure we’ve started to breakdown the monolith and the applications that run on them.

    So, now we’re taking our bundled model-view controller applications and frameworks and we’re deploying them separately as components and hopefully we’re using architectural styles like microservices so that the monolith becomes broken down into choreographed microservices that can be managed separately, okay?

    So, we have technologies that actually support this today. And so Docker, Kubernetes are some of the technologies that have come on the scene since that have allowed us to have a control plane and an environment to manage smaller-granularity applications which are hopefully services.

    So, the other thing about modern applications that I think is interesting and has fostered the adoption of these microservices and smaller components is the fact that the solution stack has become more and more commoditized, right? And so, when you think about the solution stack of network hardware, operating system, middleware layer and so on, we’re seeing a commoditization of the solutions stack from the bottom up, okay? And that is – the whole notion of cloud computing, right? – We’re no longer concerned so much about CPUs and CPU architecture, you know, X86 versus Power P Series, this or that – it sort of doesn’t matter as much anymore, right?

    And because of that, I think that has also fostered in some cases where critical proprietary software was not necessarily needed for enterprise applications. And so, when you start to break down the monolith and deploy smaller services, you’re isolating your risk because you’re isolating business functions and smaller chunks that are lighter-weight and it’s really analogous to the difference between deploying a 10-ton gorilla and deploying a colony of ants. If one ant dies it’s not a big deal, right?

    But commoditization has even spread to the way that these little ants or microservices talk to each other with the advent of API interfaces and as long as you use rest APIs over HTTP or a lightweight messaging protocol that’s pretty much the lingua franca of modern applications today.

    So, I think there’s probably this notion of componentization and that is actually fed into the notion of polyglot programming, and so enabling modern apps to be programmed in just about any language. So, you’re no longer bounded to this big, proprietary application server; you can program in just about any language, and as long as you can talk – rest over HTTP or send an A-synch message over a lightweight message hub – it sort of doesn’t matter.

    You know, you can be a Java or a dot-net bigot but, hey, the new guy who knows Python and is really good at it, he can get in on the action, too. It’s all good.

    Shimel: Absolutely. So, Andrea a lot of what you – you know, it was more than a mouthful there – and a lot of what you’re talking about really describes DevOps, right? This idea of chunking down stuff so it’s not the monolith, right, and doing small – you know, lots of smaller, little things rather than one large, bigger thing and learning and feedback looping and all of that – I mean this is – it’s DevOps 101, right?

    And to me – and this is – you know, I speak to a lot of people obviously around the world about this stuff – but to me there’s a chicken-and-egg relationship between DevOps and modern application infrastructure, development and deployment as you’ve described. I don’t know if you could have one without the other. I just don’t know which one comes first. But they’re intrinsically linked, right?

    And this is why, in my mind anyway, we need – you know, there’s a special relationship, if you will, between DevOps and modern application and how we do modern applications today.

    Martinez: Spot on, Alan. I mean, when you think about the gorilla versus colony of ants analogy. Think about having to deploy the 10-ton gorilla – it’s typically pretty complicated but there’s a lot of dependencies and release management is of utmost concern – but deploying the colony of ants you’re deploying a lot of little things at different times – so you’re achieving the multispeed IT – if you don’t have DevOps, if you don’t have that kind of automation to do the build, compile, package, test, deploy and you’re doing it intra daily – if you don’t have that automated then your cost case is going to fly out the window.

    DevOps is essential for modern applications. Period.

    Shimel: Dead on. Dead on. Amen. You know, you’re preaching to the choir here, Andrea – we’re devopsy.kinsta.cloud – but it really is essential and there is this sort of hand-in-glove type of relationship.

    We are, as I promised you when we started – the time goes so quickly and there’s more I want to cover. So we talk about how DevOps fits into the story on the how and why of modern applications.

    You know IBM has this history now – and as I mentioned to you four or four-and-a-half years ago when I launched devopsy.kinsta.cloud IBM was one of the leading advocates for what was kind of the rise of the DevOps community and culture. And then you guys had the garage method, which was really kind of intrinsically again all about DevOps and DevOps ways, if you will – how does all of that fit in to modernizing applications and the way we’re doing it now?

    Martinez: So the IBM cloud garage method is IBM’s opinionated view on how to deliver especially modern applications: It combines Agile, DevOps, Lean and our enterprise-design thinking and sort of rolls it all up into this wonderful burrito of reference architectures, practices and techniques – you know, it’s lunchtime, so I’ve got food on the mind – but it’s basically a way to help our clients act like a startup so that they can achieve the kind of agility that they need.

    So, DevOps is also about organizational and behavioral changes because that’s really paramount. At the heart of our method is culture – how to organize our teams, the collaborative practices, social coding, pair programming – breaking down the silos, right – that’s what DevOps is all about, having product owners sit with the squads, right? – sit with them. You know, DevOps is a behavior story – a tool automation story – and it’s all in the name of enabling business agility.

    Shimel: Absolutely. Andrea, I’ve got another final area I want to click on if you don’t mind. And that is for our folks listening out here – and it’s a worldwide audience at devopsy.kinsta.cloud – and I’ve traveled the world doing this, and though we all want to do DevOps we move at different speeds and we’re at different stages of our journey.

    What advice, if we can kind of give blanket advice – what advice around DevOps would you give to our listeners who – and again, Andrea, this is something you’ve probably learned, right? – I wish we all had a greenfield to play in, but we don’t, right? We have brownfields and there’s heritage apps, as you call them, and there’s modern apps, there’s old and new, fat and skinny, ants and gorillas – even burritos – what advice can you give our listeners on how to deal with all of these things?

    Martinez: I think just recognizing that you may have to approach DevOps a little bit differently depending upon whether you’re modern or heritage or even somewhere in-between. Typically DevOps for heritage applications, you’re retrofitting automation in situ, right? So, you’re sort of bringing the automation to the app. Whereas for modern applications, you definitely want to have a DevOps Day One approach, right?

    Because the ability to create a cloud-native application and have the automation in your mind right on day one is critical. But just know that you may have instances where you may not be able to bring a heritage application all the way to modern – you might be somewhere in between Fred Flintstone and George Jetson, right?

    Shimel: Two of my favorites.

    Martinez: But that’s okay, right? I mean that’s real-world. Because it may not be cost-effective to automate everything but that’s all right, you know?

    So I think we can engineer our way through some of this – and there are products out there – you know, you mentioned before that hybrid cloud was really sort of the area that I was focused in terms of DevOps – and we have proprietary products, open source products, we have our Urban Code Deploy, our IBM Cloud Private – that really sort of helps bridge the gap between applications living in this cloud or that cloud – whether they’re modern or heritage there is an answer.

    It’s not cookie-cutter, but we have the piece parts and the emerging technologies on the scene to help navigate.

    Shimel: Yep. Excellent. So Andrea that is important for people to know but where do we go – where can people go to find out more about this?

    Martinez: So I think the first place I would point them to is the IBM Cloud Garage method website – and I’m sure we’ll be providing links as part of the podcast references – but at that site you can definitely find reference architectures for DevOps, reference architectures for microservices in cloud-native development – and one of my favorites – the practices and techniques that we employ with our garage method for automation, tooling and social collaboration throughout the software delivery life cycle.

    Shimel: Perfect. So, Andrea, as I mentioned, the time here it goes so quick. It was delightful, refreshing and fantastic having you as a guest here. I’d love to have you – you know, where else are we going to learn about gorillas, ants and everything else? I need to have you back on the show. We’ll talk off-mic about it, but if it’s not too much – and we’re Florida neighbors – so I’d love to have you back here. But we’re going to wrap it up for this episode of DevOps Chat.

    Andrea Martinez-Crawford, welcome and thank you for being our guest on DevOps Chat today. We will have links to a lot of what you’re speaking about in our show notes, so folks, please take a look at that. But for now, we’re going to call it a wrap on this episode of DevOps Chat.

    You’ve just listened to another DevOps Chat and hope to see you soon everyone. Have a great day. Bye-bye.

    — Alan Shimel

  • Coming Apart in the Age of Automation

    Coming Apart in the Age of Automation

    One of the fundamental tenets of DevOps is that working in closed, departmental silos is counterproductive for creating quality software. Rather, work is done best when groups are composed of members from across the business working openly and cooperatively. Experience shows time and time again that open, multifaceted teams made up of a variety of viewpoints work better than ones that are closed and monolithic.

    Yet, when we move beyond the landscape of DevOps into American society, things look different. In his book, “Coming Apart,” published in 2012, author and political scientist Charles Murray makes the following point: Sixty-three percent of the population of the United States—white Americans—is separating into a two-class structure in which one class enjoys an increasingly stable, healthy, knowledge-driven prosperity while the other experiences declining wealth, health and educational achievement accompanied by a loosening social cohesion. This loss of social cohesion perpetuates the continuing decline. And, there is no relief in sight.

    Murray points out that while class distinction in the United States is nothing new, what is different now is that these two classes exist in silos that are closed and disconnected. While in the these past classes have intermingled, now each lives apart from one another—so much so that the classes have become almost unidentifiable to each other.

    For example, back around 1960, it was entirely conceivable that a CEO of a manufacturing business shared many of the same experiences as the less-wealthy employees of the company. They might go to the same restaurants, watch the same TV shows and maybe even drive the same make of car. Their children might attend the same schools. Today, however, it’s each to his own; shared experience among classes is becoming more rare.

    There definitely was a class system in force onboard the ocean liner Titanic. The well-to-do traveled first class, while the poor went down to steerage. But everybody boarded together, and Leonardo DiCaprio’s pauper character had a slight chance of interacting with Kate Winslet’s wealthy socialite—maybe even fall in love and get and stay married. And, when the ship went down, all aboard were at risk, rich and poor alike.

    Today, the average Joe flies in a cramped seat in economy. The CEO flies private. The economy flier probably has no idea what it’s like to board a private plane, let alone fly in one. The thought of packing a lunch beforehand to save money while traveling is completely foreign to the CEO. Each lives in a world the other can’t imagine. Again, this trend is not reversing.

    What Does This Have to do with Automation and DevOps?

    Tech culture is a prime example of this exclusive segmentation and clustering according to class. The average salary of a DevOps engineer is ~$138,000 a year, which puts the profession in or around the top 10 percent of wage earners. And, just getting hired at most tech companies requires a college degree. This is a self-selecting dynamic. Birds of a feather fly together: People who make six figures tend to hang out with others who make six figures. Likewise, people with college degrees tend to hang out with others who have college degrees. If you’re in tech, chances are you do not know many people in your day-to-day life who had difficulty in school, have worked on a factory floor or smoke cigarettes. When you and those around you make money by thinking, it’s difficult to have empathy for those whose muscles ache after spending each day stocking shelves at Walmart. You just can’t imagine it.

    Intrinsically, such homogeneity is not bad. The cause for concern is that now, once the boundaries are set, it’s difficult to go beyond them. In the past, the prevalence of shared experiences made moving up into that other, affluent world possible. Today, however, it is becoming nearly impossible. And we in tech are not making it easier. Why? One reason is automation.

    Automation replacing human labor is nothing new. It’s been going on since before Otis figured out how to make elevators go up and down between floors without requiring human intervention. Yet, this is simple stuff by today’s standards. As automation becomes more sophisticated, the degree of smarts required to work in an environment in which automation prevails grows. An engineer capable of refactoring a piece of software that does speech-to-text transformation has had significantly more education than a stenographer—which, by the way, is a profession automation is replacing.

    Automation is making it more difficult for those with only a high school education be employed. Yes, some sources claim that automation will actually create more jobs. But, how many of these new jobs will require nothing more than a high school diploma? And, once hired, how long will these new jobs be available before they are replaced with another piece of automation?

    Now, combine this trend in automation with Murray’s assertions about the growing extreme in class separation. One group is happy, healthy, pretty wealthy and productive. The other group stagnant, poorer, in ill health and continually being replaced by automation. Add in another troubling statistic: The rate of divorce in the happy, healthy, well-educated group is going down. The divorce rate in the other group is going up. (Page 146, Coming Apart, Murray) In addition, the number of single parent households among the less educated group is increasing, while the rate of single parent households for the happy, healthy, wealthy group remains low and substantially less than the other. (Page 159, Coming Apart, Murray). One group has the stability necessary to promote health and wealth in its offspring. The other group is barely keeping its head above water with little hope for better life now, and for generations to come.

    What does this mean? It means that things are coming apart.

    Probably one of the most important lessons we’ve learned in DevOps is that open systems, genuine accountability and blameless reflection combined with a cross fertilization of ideas between different groups makes for a better, more productive work environment. This thinking can and does go well beyond software. Anybody who has experienced the waste and frustration of a closed, siloed organization understands that open is better. We in DevOps understand the the smarter we all are the better off everybody is. Sharing knowledge and expertise is not a zero sum game.

    According to Murray, we are no longer all passengers on a common ocean liner. Today two ships are sailing side by side. One has an able crew with enough supplies and lifeboats for everybody aboard. The other sails along somehow, with dwindling resources and a few lifeboats. We in DevOps are are snug and secure in the first ship. For those in the other ship, the clock is ticketing and the ship is taking on water. Those of us who care about the Big Picture understand that things need to change, that we need to come together rather than come apart. The question, how? This is the question I will leave to you to answer.

    I look forward to reading your ideas about how to bring us together in the comments section below.

    — Bob Reselman

  • Blockchain: A Threat to DevOps—and How Engineers Can Respond

    Blockchain: A Threat to DevOps—and How Engineers Can Respond

    Blockchain is one of the hottest topics in the IT world today—and that creates a challenge for DevOps professionals. Here’s why, and what DevOps engineers can do to remain relevant.

    Blockchain, Fat Protocols and a New Generation of Applications

    To understand why blockchain threatens to decrease the role played by DevOps engineers in software platforms, you have to understand the difference between blockchain-based applications and traditional applications.

    That difference was summed up most famously in an article by Joel Monegro about “fat protocols.” Monegro convincingly argued that prior to the introduction of blockchain technology, most software stacks were composed of “thin protocols” and “fat applications.”

    What he meant was that in most traditional web applications, the majority of the value and functionality lies in the application itself, rather than in the protocols on which it runs.

    In other words, if you write a PHP application, most of the time that you invest and the value you create center around the application code. The protocols that allow the application to work, such as HTTP, are relatively simple and uninteresting.

    In blockchain-based applications, by contrast, the magic happens chiefly at the level of the protocol. The main job of these applications is simply to access that protocol. As a result, the applications themselves are relatively unimportant.

    How It Changes DevOps

    What this means for DevOps is that, if blockchain becomes as central to the software platforms of the future as its proponents hope, application code will become much less important than it is today.

    By extension, the people who write and manage that code—DevOps engineers—will have less of a role to play in software deployment.

    If you take a look at how most existing blockchain platforms operate, it’s easy enough to see how this trend plays out. The amount of effort required to write and maintain a basic “smart contract” application that runs on the Ethereum blockchain, for example, is pretty minimal. You don’t exactly have to be a DevOps genius to churn out some if-this-then-that code that interacts with Ethereum.

    The same is true of an application that writes data to the Bitcoin blockchain to record a real estate transaction, for instance, or one that timestamps a document to a blockchain to create a record of the document’s existence.

    In these use cases—as with almost all use cases associated with the blockchain—the role played by DevOps engineers is relatively small, because there is not much code to write or manage to deliver the platform’s core functionality.

    Blockchain-Proofing DevOps

    Yet, if the blockchain revolution does come to pass, it won’t necessarily be bad news for DevOps experts.

    Even though the core application code required to interact is minimal, crafting platforms that are secure and provide a solid user experience takes more work. This is where DevOps engineers can help.

    One of the most glaring problems with many existing blockchain platforms is that their interfaces tend to be difficult to use. Related software security problems are also well-known.

    In addition, some platforms have performance and scalability problems. Bitcoin advocates like to talk about how digital currency will make transactions much smoother, but the reality is that it can take hours to confirm a Bitcoin transaction. That’s a big problem if you want to buy and sell things with Bitcoin.

    Arguably, these issues originate in part from the fact that many of the people currently designing blockchain platforms are good at recognizing how decentralized, distributed databases can drive innovation, but less adept at writing, maintaining and scaling software and the databases that power it. They are not, in other words, DevOps people.

    By helping to build out blockchain applications so that they are actually usable, secure, efficient and scalable, DevOps professionals can ensure themselves a role to play in the platforms of the future. At the same time, they’ll help the technology transition from its current state of hype into something that can be used to solve everyday problems.

    — Chris Tozzi

  • Using CALMS to Assess an Organization’s DevOps

    Using CALMS to Assess an Organization’s DevOps

    Of the tried-and-tested frameworks that allow enterprises to assess DevOps in their organization and how it can be improved, the CALMS model remains particularly useful.

    CALMS, which stands for Collaboration, Automation, Lean, Measurement and Sharing, is particularly helpful for analyzing an organization’s DevOps structure, and ultimately, its utility in any organization. The CALMS framework covers all stakeholders within DevOps, including business, IT operations, QA, InfoSec and development teams, and how they collectively deliver, deploy and integrate automated processes that make business sense.

    “DevOps as a technique is slowly but steadily maturing, so it’s good to see general assessment methods like the CALMS model,” Holger Mueller, an analyst for Constellation Research, said. “The CALMS model gives a good frame of reference to compare the maturity of a DevOps team, and as such,  is invaluable for assessing the state of teams for the transformational change that goes with it.”

    Applying CALMS

    Here are a few ways CALMS can be applied to DevOps for enterprises either thinking about shifting to a DevOps structure or seek to make improvements to an existing deployment.

    Culture

    It is long-established that technology adoption must be to serve a business need rather than investing in technology for its own sake. This shift in mindset applies to how the “culture” component of CALMS supports how the forecasted ROI associated with automating a process must be championed across the DevOps team. This mindset is especially important for getting the non-technical business teams onboard, Mueller said.

    “DevOps must have the backing from the business executives. That’s a crucial factor in the culture part,” he said. “One thing software teams can do is use successful software deployments to help convince the business executives in DevOps to make the investments. Those are the kinds of tribal events that every DevOps organization needs.“

    Automation

    Netflix is well-known as an exemplary case study for DevOps automation. Among other things, it can deploy code and software updates in a matter of minutes across its entire massive infrastructure, many times throughout the day. But Netflix’s example of automation does not take into account what can go wrong at firms that want to follow Netflix’s example when automating their software deployments and updates, Mueller said.

    “The risk is always deploying too fast and you end up deploying bad code,” Mueller said. “Automation, of course, needs to take this into account and compensate. But not everybody can do that.”

    Lean

    Once completed, it is relatively easy to document cost savings by eliminating resources. Within the CALMS framework, the corresponding “lean” component in DevOps is thus relatively easy to assess, Mueller said.

    The good thing about DevOps, Mueller said, is companies can come to a consensus ahead of time regarding what they consider to be a lean operation.

    However, he added, “There is always the risk of being so lean you begin to err on the QA side.”

    Measurement

    The success of software deployments is relatively easy to measure once completed. However, attempting to measure future deployments as part of a forecast model is, of course, much more challenging.

    “It can be surprisingly tricky to measure how good DevOps is ahead of time,” Mueller said. “Measurements should thus allow errors to be pinpointed  quickly during the post-deployment stage to fix the code if needed very quickly.”

    Sharing

    Sharing, in many ways, overlaps with culture. This is where assessing whether all of the different teams within DevOps are working together and communicating comes into play.

    “Thanks to  DevOps, the days of the lone developer are long gone. But sharing is not always easy,” Mueller said. “Even within separate teams, it is easy to fall into the trap of wanting to get your own work done without necessarily thinking about the team as much as you should.”

    The End Result

    While applying CALMS to assess DevOps never hurts, the framework is still not as important as one of the main objectives of DevOps—namely, using technology to make organizations’ operations more agile and reactive to customer needs, Mueller said.

    “At the end of the day, assessment methods such as CALMS are great, but they are never as important as focusing on implementing next-generation applications,” he said.

    — B. Cameron Gain

  • Functional Programming: Island of Misfit Functional Programming

    Functional Programming: Island of Misfit Functional Programming

    The age of functional programming is dawning. The hype cycle has heated up, and IT departments are getting both real and perceived benefits out of the idea that a function runs on demand only.

    For some, the benefits are very real. Bursty processing, or things that are frequent and quickly resolved, see a benefit from being implemented on functional architectures, and the cost of functional architectures is arguably far better than the cost of cloud instances. I say “arguably” because you can always cram more onto an underused cloud instance, but you pay as you go—even more literally for functional programming, so additions each have an incremental cost. But it is incremental, and you have the power to choose whether functional is right for any given bit of the architecture.

    So why the title? Remember The Island of Misfit Toys from the much-beloved Christmas story, “Rudolph the Red Nosed Reindeer”? They were all just a little off. In a world flooded with perfectly good toys, they were left unattended and unwanted.

    That is a risk functional runs in the long run, also. The idea that you can pop a function out there, configure the access point (almost ubiquitously a web application firewall entry point, but things change so we’ll stick with the generic “entry point”), and start sending requests is great. The fact that you only pay for that bit of time when your request is actually being serviced is great, too.

    But this ideas assumes security is baked in at the functional level. If you are deploying this function anywhere with a public IP, it assumes hardcore security is baked in.

    And failure to have that security baked in is the first reason you might have a misfit toy.

    By definition, functional programming-based systems are complex systems. They are the ultimate evolution of microservices. They will suffer all of the headaches and heartaches associated with SOA and add on the issues with REST versioning, etc. There will be 50 or 500 functions, each clipping along and doing its thing, composed to make a single application (in a purist world, composed in a functional programming app).

    Some of these functions will become outdated and unused. You can’t leave them laying around, waiting to be abused. Indeed, a new form of financial attack might be to look for just such abandoned toys and start calling them repeatedly and rapidly.

    Imagine coming in one day and having Finance ask you why your bill at functional provider X tripled in the last month, only to find a function you left hanging around was being called for no good reason?

    But the complexity inherent in lots of small bits of code, each doing a specific task, pretty much guarantees there will be cruft left lying around unless you are very careful.

    And that, my friends, is (finally, I know) the point of this blog. Our monitoring tools today lean toward watching the performance of the application, but you need more than that before you go all-in on functional programming. You need build tools that can tell you when a given function is no longer called—from anywhere. That is a tall order which none of the previous distributed methodologies has managed to master, but it is more important in a world where you have functions sitting in various public clouds with public-facing IP addresses.

    There also needs to be a definitive source code scanner. Those are slowly getting better, but imagine if a library the build system pulls in and uses for 20 or 30 different functional programming microbits becomes compromised? We’ve seen enough instances of ignoring the problem is begging to be a victim, so scanning on build is more important with more systems using external libraries. Or more accurately, with external libraries being pulled into more microservices. There are companies/service providers that will validate your external dependencies and only let you load open source libraries they have certified as safe. I’ve never used one, but they’re worth looking into.

    A list of entry points and places they are accessed from is useful for internal-only applications. You can’t do that with a publicly exposed REST API that anyone can call, of course. I’m a developer and a D&D player, so I’ll use that example: Wizards/Hasbro cannot control where this API is being called from. The same is true for any web services APIs that exist to give others access. But internal APIs that are an integral part of internal systems and not called externally? Those you need an automated way to find references to them in internal source and keep a count. Much like garbage collection, you’ll want to take down ones whose count reaches zero.

    The thing is that in many ways functional programming reduces operational complexity. It certainly reduces operational overhead. But that complexity is replaced with a different kind of operational complexity; maintenance becomes a bigger issue, and the already occurring breakup of code into smaller chunks increases, bringing cross-reference complexity along with it.

    Keep that in mind. You will have orphaned functions, you will have security concerns, you will have changed operational complexity. Plan for these things from day one. They are not at all deal breakers, and the benefits of functional are already clear in certain verticals with more general benefits being discovered as I type. But they’re the new problems that will require answers in this new architecture.

    So, build in oversight and tools from the beginning and go see how functional programming could benefit your project. At this time, it isn’t the answer to every problem, but—like most cool new IT things—it is another tool to have at hand when solving problems for the business.

    And don’t let your functional programming microservices end up on the Island of Misfit Functional Programming.

    — Don Macvittie

  • Repeat Warning: There is No Silver Bullet in DevOps

    Repeat Warning: There is No Silver Bullet in DevOps

    As the cycle of DevOps is repeated in a growing list of organizations, I feel compelled to reiterate the warning that this is not the pinnacle. Anyone who has been around for a while knows that the current fad is not the last fad.

    [[Cue DevOps people screaming at my choice of the word “fad”]]

    Of course it’s a fad. DevOps (and to a much lesser extent, agile) is the cool toy in the midst of Gartners’ (in)famous hype cycle. That doesn’t mean nothing will come of it; it means that people freak out when you tell them it doesn’t solve every problem.

    All of the process/solution fads that have come along have offered some benefit to IT. DevOps promises to offer more, and in many environments it does. But grabbing your broadest brush and screaming, “DEEEEVVVVVOOOOOPPPPPSSSS!” while painting everything in sight is not problem-solving; it is thinking there is only one path to quality and it flows through the Chosen Process.

    The reason DevOps is different from previous hype cycles is obvious: It has the built-in assumption that this is not the end state. It assumes you will keep moving forward and things will change. Previous “new way of doing things” ideas have assumed that there was some nirvana you would get to and everyone would relax there, sipping ambrosia and enjoying immortality. DevOps makes no such claim. About as close to a final state as it gets is increased communications between the various parts of the DevOps life cycle. And that is because there is only so far you can go with increased communications before you’re flooded. And even that leaves room for new tools such as Slack to augment communications.

    But don’t look at every problem with DevOps blinders. This is the real world, and while some will (possibly correctly) claim that every software dev/deploy cycle can benefit from DevOps, the real question is not “Can it benefit?” but rather, “Is the cost/investment/risk less than those benefits?” And to the chagrin of those who live and breathe DevOps/agile, I’m afraid the answer to that question isn’t always a resounding “Yes.”

    I’m undeniably a fan of both agile and DevOps. What I’m not a fan of is finding the nearest round hole and cramming everything—including square pegs—into it. Look at each project/process objectively. As a simple and blog-length example, let’s examine standalone app that does some important back-end process and is only updated once or twice a year: Why ever would you rip the process for that apart, invest man-hours to bring it into the DevOps and agile folds, then … only update it once or twice a year?

    If you are building a new project, and you have DevOps processes in the building, it would take a convincing argument to not use them. The same should be true the opposite direction. If there is an existing project that doesn’t have delivery delays, it should take a convincing argument to move it to a whole new development/deployment methodology. Choose wisely. Invest resources where they’re required, not where ever the broad brush falls. IT has enough work to do, don’t add to it, just so you can say “We’re a DevOps shop.” Better to say “We’re a right tool for the job shop.”

    And keep kicking it. Business doesn’t run itself, IT runs business. Keep making it work.

    — Don Macvittie