Tag: it

  • DevOps Deeper Dive: IT Terminology Matters

    DevOps Deeper Dive: IT Terminology Matters

    Much like any other profession, the IT industry does not exist in a vacuum. Social upheaval will have as much impact on IT professionals as it does on any other. As conversations concerning race relations become more heated and, hopefully, elevated, many in the IT industry are reconsidering the use of terminology such as master/slave to describe the relationship between applications and devices.

    GitHub this week announced this week it will be changing the term “master” as it is applied to its repository to a neutral term. Use of the phrase master/slave as a means to describe relationships between software and hardware has been employed since the very early days of IT. In fact, some would note the concept of slavery stretches back to the dawn of time.

    Nevertheless, too many of the terms used in IT evoke a sense of domination that reflects a white, male view of the world, said Dr. Shuli Goodman, executive director of LF Energy, an arm of the Linux Foundation committed to combating climate change by modernizing the power grid using open source software.

    “Language reflects our mental models,” she said.

    The IT industry in general would be better off embracing, for example, biological models rather than terminology that suggests domination and submissiveness, noted Goodman.

    Even IBM, which provides some of the oldest and most venerable platforms in the industry, is open to having this conversation.

    The company is committed to recognizing the experiences of everyone in the IT community, said Sanjay Chandru, director of IBM Z DevOps.

    “If that means we need to have a conversation about terminology, we’re open to that,” he said. “Personally, I think GitHub did the right thing.”

    The time to make a mental shift might never be better, said JFrog CEO Shlomi Ben Haim. The IT industry is transitioning toward a more distributed approach to computing that relies less on centralization. As more workloads shift to the edge, IT environments will need frameworks that span everything from the edge to the cloud, he said.

    As a result, the IT industry as a whole is shifting more toward a peer-to-peer relationship between software and hardware, he added. “We need IT to be more flexible.”

    The history of IT is marked by pendulum swings between centralized and distributed computing. Arguably, the rise of cloud computing represented a shift back toward a more centralized approach to computing that has a lot in common with the way mainframes were deployed and managed more than 50 years ago.

    PCs, on the other hand, were at the forefront of a wave of distributed computing that in many cases simply became too unwieldy to manage. Cloud computing afforded IT organizations an opportunity to centralize the management of workloads. However, with the rise of edge computing, workloads might soon be more distributed than ever.

    As is often the case when it comes to IT trends, it’s likely new terminology will soon emerge to describe the relationship between highly distributed instances of software and hardware. Hopefully, more perspective will be brought to bear not only on what those terms mean from a technical perspective but also how they might be perceived both inside IT and socially.

  • Setting Up Google Authenticator on Multiple Servers

    Setting Up Google Authenticator on Multiple Servers

    Google Authenticator is pretty great. It allows me as an administrator to set up and configure multi-factor authentication into my UNIX boxes without having to spend money on a tool like YubiKey or RSA tokens. It’s easy to set up on any type of phone—no specialized hardware or dongles needed. It’s also pretty cool in that you don’t have to have network access from the server to the outside world. Since Google Authenticator is time-based, it doesn’t need to send an SMS or do a callout to a centralized server to get the current valid token.

    What is a bit painful, though, is needing to have a different Google Authenticator token for every one of my servers. The standard setup would have you run the google-authenticator command on each and have as many tokens as you have servers. Obviously, this quickly becomes unwieldy and untenable.

    Instead, I want to have one token for multiple servers. Here’s how I installed and configured Google Authenticator on each system.

    First Machine

    On my first machine I’m going to install Google Authenticator and create a secret key—the exact flow I’d use normally.

    1: Install Google Authenticator. This is pretty well-documented; examples can be seen at untrusted connection and How-To Geek. I won’t walk through each step since this part varies from OS to OS; the rest of the steps are identical, however.

    2: Restart the ssh service

    $ sudo restart ssh

    3: Run the google-authenticator command to generate a secret key for your account, which you’ll store in your phone. This information will be stored in a configuration file that we’re going to get into later. I don’t need to comment that you actually have to enter the secret key into your phone, do I?

    4: Give it a spin. From another shell go ahead and try it out.

    5: Let’s take a look at the configuration file. We’re going to copy these contents to our other machines that we want to have the same secret key.

    Installing Google Authenticator on Additional Machines

    For all other machines I’m going to install Google Authenticator as normal, but I’m going to use the secret key from the first machine. This will let me log in to each of them using that same secret key that I stored from the first machine.

    1: Install Google Authenticator. Again, other places describe this in detail. We’re going to install the program but not do the creation of any secret keys

    2: Create the configuration file and add the content that we got from the other machine.

    3: Set permissions for the configuration file.

    4: Restart the ssh service.

    5: Test the login.

    Voila! A shared secret key across my servers! Happy day.

    — Rajat Bhargava

  • Predict 2020: What Will the New Year Bring?

    Predict 2020: What Will the New Year Bring?

    With the holiday season upon us, our thoughts naturally turn to the next year and what it has in store for us. Will we come into more money? Will we find true happiness? Will there be better integration between DevOps and security? Will there be more Kubernetes instances? The first two may be a little hazy, but it’s a good bet the second two will be discussed during Predict 2020 Virtual Summit, Jan. 23, 2020, where an all-star lineup of industry luminaries will offer up their visions for the future.

    Crystal ball? Check. Swami hat? Check. Insight relevant to the industry? Check. Very smart people who know what they’re talking about? Double check.

    Similar to last year’s event, Predict 2020 will feature a virtual environment with a conference lobby, presentation theater, expo hall and more. More than a series of YouTube live presentations, it is truly a conference experience from the comfort of your desk.

    Speakers

    Our keynote speakers for this daylong event include analysts, practitioners, venture capitalists and thought leaders from the realms of DevOps, cloud native, cybersecurity, digital transformation and IT. Each will share their best predictions for the year 2020 and beyond.

    Among those slated to speak are:

    There will also be an exhibit hall where you can interact with other attendees and sponsors, watch videos and download more information.

    It should be a great day of learning and networking right from the comfort of your own chair.

    Registration and Sponsor Info

    You can register now at https://predict2020.io. Attendance is free.

    If you are curious about what the experts, pundits and luminaries think will be the big trends and stories of the coming year, mark your calendar and attend Predict 2020.

    Save Your Virtual Spot

    — Alan Shimel

  • Why Workload Security Is Not Just for IT Anymore

    Why Workload Security Is Not Just for IT Anymore

    Once upon a time, workload security (which means making sure an application and its environment are configured and deployed securely) was something that developers didn’t have to think much about. Developers’ only real security responsibility was to write secure code. After they passed the code off for building, testing and deploying, it was someone else’s job (specifically, the IT department) to secure the workload of which the code was a part.

    That’s no longer the case. Today, workload protection is the responsibility of the entire DevOps team, not just IT engineers.

    Let’s explore why, and what this change means for developers.

    How Security Problems Flow Down the CI/CD Pipeline

    To understand why workload protection has become everyone’s responsibility, you have to understand how DevOps and CI/CD have given rise to new types of security challenges.

    In an organization that has embraced DevOps, code is intended to flow continuously, in a so-called CI/CD pipeline, from development to testing, to building and, finally, to deployment. To keep the CI/CD pipeline flowing smoothly, DevOps teams typically strive to standardize and automate as many processes as possible.

    From the perspective of efficiency and reliability, standardization and automation are great. They are key to enabling continuous software releases.

    When it comes to security, however, standardization and automation have a downside, which is that a configuration problem introduced at one stage of the pipeline can flow down the pipe and reach production environments easily without anyone noticing.

    This is true for two main reasons. First, standardization and automation minimize the amount of human intervention and oversight that go into the CI/CD process. Again, that’s exactly the point, and it’s a benefit in most respects. But when it comes to security, less human intervention means a greater chance that a security problem will go undetected (particularly if you don’t have automated security tests or audits in place to catch the issue).

    The second major risk associated with standardization and automation within a CI/CD pipeline is that sometimes, developers might set a configuration that they don’t intend to be used in production, but is pushed into production nonetheless by the automated pipeline.

    For example, developers might place code inside a container to help with testing or staging, without intending for that same container to be used in production (instead, they assume the code will be repackaged before being deployed). Because they don’t intend for the container to be used in production, they don’t use a secure configuration for it. Maybe they let it run as root, for example. Then, if communication breaks down and a release automation tool pushes that container into production without changing the configuration, a container with a security flaw will end up being deployed.

    To learn more about security and compliance for DevOps, check out our recent webinar.

    Extending Workload Protection Beyond IT

    In a perfect world, the IT team would be able to catch these flaws. But the reality is that in a fast-moving CI/CD environment, it’s not realistic (or fair) to expect IT alone to make sure that workloads are configured securely before they are deployed.

    Instead, the entire DevOps team needs to take responsibility for workload security.

    What that means specifically will vary from organization to organization, but in general, extending workload protection beyond IT means the following:

    • Making sure that developers (and not just IT engineers) understand workload security best practices and why they are important to follow at every stage of the CI/CD process.
    • Establishing and enforcing (via automated audits) policies for how workloads can be configured at any stage of the CI/CD pipeline. For example, the DevOps team as a whole might agree not to run containers as root, even if it’s only in pre-deployment.
    • Enabling runtime protection by scanning for vulnerabilities that appear within applications and environments once they are live.
    • Securing data at all stages of the CI/CD pipeline and scanning data for signs of intrusion or malicious code.
    • Performing continuous security monitoring and vulnerability detection (both pre-deployment and post-deployment) to catch issues as quickly as possible, even if they have slipped through the cracks of earlier security tests.

    Conclusion

    It would be nice for developers if workload security was not their responsibility. But in the age of CI/CD and DevOps, they no longer can hand off that burden to the IT team. The IT team still has an important role to play in making sure workloads are deployed securely, but effective workload security for DevOps starts early in the CI/CD pipeline—with developers. Code moves too quickly down the pipeline for developers to assume that they can safely do one thing with a workload and have the IT team change it before the workload is deployed.

    Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

    Sign up for a free trial of Symantec CWP.

    — Chris Riley

  • DevOps Chat: Digital Transformation with Paul Chapman of Box

    DevOps Chat: Digital Transformation with Paul Chapman of Box

    It seems every organization is chasing digital transformation. Some companies are succeeding, while some are wallowing a bit, trying to figure out how to do it. Box is a company that is both successfully navigating digital transformation and being a catalyst for digital transformation at other organizations.

    In this DevOps Chat we speak with Paul Chapman, CIO of Box, about digital transformation for both Box and other companies, and he gives us his own take on what the environment is like for companies and what they should do to thrive today. Great conversation, enjoy!

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps Chat. I’m really happy to have as a guest on today’s DevOps Chat, Mr. Paul Chapman, CIO at Box. Paul, welcome to DevOps Chat.

    Paul Chapman: Thanks. Great to be here, Alan.

    Shimel: Great to have you here. So Paul, before we jump into a couple of the items we wanted to talk about. I guess in case anyone in our audience maybe is not familiar with Box or yourself, why don’t you just quickly level set your background, Box, and we’ll jump in from there.

    Chapman: Sure. Well, maybe I’ll start with just a little background, accelerated bio of sorts. Been in the technology space for quite some time now. I like to joke that although this is the truth, I was a COBALT programmer and an RPG programmer back in the late ’80s. So I’ll fast forward to today and say a lot has gone on in between. I’ve had to reinvent myself many times over to stay relevant. I often tell my team that the pain of change is mandatory. It’s the suffering that’s optional.

    So get comfortable with being uncomfortable if you’re in the technology space. It’s never boring. That’s for sure. I’ve done a lot of things in between but thoroughly enjoying my time over here at Box. We’re born in the cloud, grown up digital company. Very forward thinking, innovative. And we’re helping tens of thousands of organizations around the world to help to transform and digitize the workplace.

    Shimel: Fantastic. So Paul, you mentioned Box and we talk about unicorns and cloud natives and these kinds of things. Box is certainly a member of the club. And while they themselves, generally, these kinds of companies like box eat their own dog food in terms of what they preach and everything, we almost take for granted the transformative wave that they’ve ushered in. Again, I’m your age or maybe more. I remember the 1984 commercial with the hammer –

    [Crosstalk]

    Chapman: Mm-hmm. The Apple one, the famous Apple one.

    Shimel: The Apple commercial. Sure. The Mac commercial. So in a lot of ways, companies like Box and as their poster child for it have broken through the silos that in the IT world, you and I grew up and kinda held us bound. If you can, give our audience a little bit of – I don’t know if that was intentional that it breaks down silos or it was an unintended consequence but talk to us about how is it helping to break down. How does it usher in what – digital transformation is something everyone talks about. How does it help with that?

    Chapman: Yeah. Well, I think when you look at – and I’m gonna sort of just geek out a little bit and share that one of the things that I have – now, we’re starting to see some maturity in what I would call sort of the modern reference architecture for how you run your IT service today or business services today, is that when you look back at sort of the technology that we invested in in the ’90s and in the ’80s, which at the time, was the most modern advanced technology I should say, at the time. Unfortunately, it was architected in such a way that it was very siloed and you ended up sort of building up these sort of monolithic sort of application stacks where you went to sort of the oracles for everything or the SAPs for everything and it was very hard to integrate.

    And unfortunately, what happened is is you sacrificed a lot of what I would call best of breed capability and innovation in that model and because that architecture doesn’t, in a sort of step wise, linear way evolve to support today’s way of working – today, we have a new style of employee. One that has grown up digital that’s been educated by consumer experiences that expects a certain set of things when they enter the workplace. You have a new style of workplace. It’s very open and social and collaborative.

    You have this new style of IT that’s evolved to support that. And when you look at what’s actually happening, the modern architecture is built around this best of breed ecosystem and there’s innovation going on everywhere. But the innovation is generally organizations are picking the area that they’re gonna be the most innovative in and they maniacally focus on the innovation in that space. So they’re the best at what they do and Box is absolutely the best at managing unstructured content for the enterprise with the best compliance and regulatory and so on. And security and risk and all those things.

    And then there are other companies that are the best at messaging and then there are others that are the best at certain types of collaboration. And what we get to do now is to start to bring all these services together because they’re built to interoperate which the architectures of yesteryear weren’t and we get to bring and curate that into the experiences we bring to our employers, partners, suppliers, and customers and therefore, we’re starting to create more automation, more digitization across this best of breed ecosystem. Long winded answer but there’s a lot going on in there today.

    Shimel: Oh, absolutely. So let’s pick into a couple of those areas. Number one is lock-in or the – we used to suffer with these large stacks. You were locked in though. Right? I was talking to someone earlier today, a start up who managed Macs for enterprises. Right? And why haven’t we seen that before? Well, maybe there were enough Macs. But we’ve all suffered from lock in in our technologies.

    Chapman: Yeah. And we don’t like it. We don’t like the way it makes us feel. We don’t like to feel captive or without choice and really today, freedom of choice is extremely important. And so what I do know, though, and this is something that I’ve certainly come to appreciate is especially if you are, as you think about a much more heavily cloud based footprint, you have the freedom from infrastructure. You have the freedom from direct sort of operational responsibilities that in our past lives, we have significant operational responsibilities managing a lot of technology debt and infrastructure and so on and we had to manage service levels, capacity, performance, backups, failover, all the things that are just really keeping the lights on.

    We’re not adding any material value necessarily directly to the businesses. It’s the things, the services that run on top. And so what I’ve seen is is that now as you start to move to a cloud based model which is much more subscription based. The on ramps are a little smaller. The off ramps are a little smaller. The ability to change out services for services that may not be as innovating as fast as others as is a little easier but I think the key thing is this. Every one of those services that you subscribe to, it’s a mutually beneficial outcome. They have to earn your business on an ongoing basis.

    Shimel: Yep. On a minute by minute. Not even daily.

    Chapman: Because if not, the subscription stops and you move it somewhere else and if they are not maniacally focused on innovating in their space, having highly reliable, scalable services, having services that meet your compliance and regulatory requirements and having services that meet your trust and risk criteria for that particular service, they don’t have a business. And so the beauty of this model or this new emerging model, I should say, is that in the old ways, they’d sell you software and then you sort of … you get locked in and it’s hard to move. Now, we think about it as all the time. It’s about the customer all the time. How are we making our customers get more value from their investment in us and how can we make sure we’re providing reliable services and innovative capabilities that they’re subscribing to to maintain them as a customer. And that’s good for us.

    Shimel: Absolutely. So I would even go further, Paul. I’d say the hardware vendors locked you in more than the software guys even did. Right? When you made decisions, whether you were on Solaris or this flavor of Unix or Microsoft or what have you or HP, I mean, HP, and I know you used to be at HP, no disrespect to them, but they were really good at talking about freedom and best of breed while locking you in tighter than a drum. But today, so to me, this all refers to something that I call portability. We have, as consumers, as customers, we have such portability today where we can take our stuff up and go. It’ll run anywhere we want, just about.

    Chapman: That’s a great point. Actually, a really good point. And the infrastructure, I was focusing on the services piece but you’re absolutely right. As I mentioned, the freedom from infrastructure in the cloud world is like no offense to the infrastructure providers. It’s just I add more value to my organization when I’m not focused on those things. It’s a give back of time and one of the most precious things we can give anybody is time. And I’m able to use that time to do what I would consider much higher value, contribute at a much higher value to the organization because of that.

    Shimel: Absolutely. Paul, I wanna transition to another topic that we spoke of but I think you gave me a great segue here and that is that when we talk about things like transformation and thriving and leveraging what we have, what the technology world has to offer us today, so much of it, frankly, isn’t hardware or even software. The success or failure of organizations is often based on their culture and their people. Right? And some, we live in a gee whiz world where we take things, we were talking off hand about answering the doorbell from China, but organizations can’t really thrive, compete, and transform without that cultural sort of happening. Curious on your thoughts on that.

    Chapman: Yeah. Probably … at Box, we talk a lot about the future of work and also, we talk a lot about it’s not about rewriting your software. It’s about rewriting your company. And when we look at companies that … if you look at just some of the statistics, 52 percent of the Fortune 500 have disappeared since the year 2000. And if you do the math, that’s more than one per month. And a lot of people get into this techno-panic thinking it’s technology that’s disrupting these companies but the reality of it is is technology is enabling that disruption but the technology that’s doing this is available to everybody including the incumbents that have built their business models and their operating models on sort of a sort of legacy way of working. And you have – if you look at the companies that are disrupting, it’s because they have a different operating model. They have different business models.

    They operate culturally very different and the cultural shifts are really, really hard, especially in organizations that have become very established in their markets because that’s what got them there. And the reality of it is we used to coin this term sort of this frozen middle part of an organization that didn’t necessarily have – doesn’t necessarily have aligned incentives to change. Because it’s like what’s in it for me on the other side of this change? And they say at any given point, a third of an organization, and this changes, varies from company to company but a third or an organization knows where you’re going and how you’re gonna get there. A third doesn’t but they’re willing to learn and invest and figure it out and a third doesn’t, never will, isn’t interesting, da, da, da, da. And that’s resistance.

    And the resistance to change has to be resolved. A lot of companies will figure out maybe what they need to do and even why they need to do it but it’s the execution of the how and sometimes, that how is where it really holds people back because they realize that they may not be able to get there with the culture and the people they have. And they switch out leaders and so on and I can share some more in what I’m seeing companies that are able to do this successfully. Most of them, it does take sort of what I would call sort of breaking the company somewhat in order to ______ them.

    Shimel: No, no, no. You gotta burn it down. Right? And I don’t wanna burn it down. But there has to be fundamental change. Last question because I know we’re running low on time but how important is leadership? Right? As a CIO, this is kinda your … this is a big part of your role, right? But how important is leadership in making that transformation?

    Chapman: It’s absolutely key. You can’t do it without the right leadership mindsets and call it coalesced support. So I’ll give you a recent example that I was talking to a CIO of a very, very large company that had been struggling with, call it, reinventing itself and reestablishing itself in a new modern digital world and was starting to make some, is starting to make some success there. And one of the questions that we often get asked as CIOs is, “What’s your partnership model look like or your engagement model look like with the business and how do you think about change management?” And like I said, I went to school to learn how to do programming and COBALT and RPG. I never went and got a PhD in change management.

    [Crosstalk]

    Yeah. I’m not an expert at trying to change the mindsets of thousands of people across an organization when at least a third of them, based on our numbers, don’t even want to. Right? I’m jesting a little bit. The CIO is one of the best partners to enable change but isn’t necessarily always in the best position to drive that change across the organization. You have to have leadership alignment and so on and the company I was talking to, I was talking to the CIO and he was asked that question. “What’s your – people are interested because they’re starting to see meaningful change.”

    And they asked him about his relationship model with the business and he said, “Here’s what happened. When we got our new CEO, he went to all of the heads of all the different business functions that we have and said, ‘If we are going to transform, if we are going to think like a digital company, if we’re gonna think like a technology company and we’re gonna disrupt, it’s incumbent upon every single one of you business leaders not for IT to come to you and say, ‘Here’s what our model for working with you is.’ It’s what is your model for working with IT? What is your model for working with the CIO?’”

    And he said that once that accountability came into the business owners, he said it just greased the runway for the CIO and organization to enable accelerated change across the organization because it wasn’t incumbent upon the CIO then to drive that change. It was to enable the change. And I actually think that that’s something that is key here is we have to rethink the model of how we engage and operate, not just it’s a technology solve.

    Shimel: Right. I agree with you. First of all, I wanna apologize for taking up much more time than I think we booked but it was a great conversation. It was kind of fascinating. Maybe we can have you on on another chat at some point or through the other vehicles we use. But look, continued success with Box. We’re customers.

    [Crosstalk]

    devopsy.kinsta.cloud only for our most important data. But anyway, thanks for being our guest on DevOps Chat today and we’ll speak to you soon.

    Chapman: Appreciate it. It’s fun hanging out.

    Shimel: All righty. This is Alan Shimel for devopsy.kinsta.cloud. Thanks for listening. This is another DevOps Chat. See you soon everyone. Take care.

    — Alan Shimel

  • 5 Things That Will Be Automated in 2018

    5 Things That Will Be Automated in 2018

    We may not have fleets of robots waiting on us hand and foot yet, but the automation revolution is in full swing. With automation becoming more apparent in daily life, some of the misguided fears over the concept and its potential to eliminate jobs are slowly being replaced with the view of automation as an opportunity. And given that IT departments are powering today’s businesses, few can capitalize on this opportunity more than enterprise IT.

    Across industries, the pressure to deliver innovation faster continues to grow, and with budgets and headcounts remaining relatively stagnant, organizations not adopting an automation strategy are being set up for failure. Automation allows computers to do the mundane tasks—and increasingly, even the not so mundane—freeing staff to focus on innovation.

    Automation Everywhere

    While 2017 demonstrated that automation is key to IT optimization and digital transformation, 2018 will be the year IT automation truly hits its stride, with widespread, systematic adoption across industries. So what trends in automation should organizations be looking to embrace next? These five areas in enterprise IT are prime to be automated in 2018:

    Networks

    Networks are arguably the bedrock of enterprise IT, yet true automation of the network stack has been nearly nonexistent. In fact, managing networks hasn’t changed significantly in the past 30 years. Network engineers still are logging in to individual devices and hand-crafting configurations, leaving network teams increasingly isolated from the DevOps revolution and slowing digital transformation.

    This year, network automation will move full steam ahead in the enterprise—and there isn’t really an option for it not to.

    With the ongoing march to cloud, new and potentially massive IoT deployments and increased pressure to modernize internal IT for efficiencies, network engineering must have the same focus and attention that server and app engineering has had in recent years. Network teams cannot remain isolated and resigned to merely maintaining the status quo; we should embrace them and show them how to reap the same benefits combining Dev and Ops has provided.

    Bringing the automation of networks into the fold of DevOps will enable tasks to be executed with increased cadence and with a higher degree of accuracy, while increasing collaboration between teams that are critical to the success of modern application architectures.

    Infrastructure

    To run business systems, you need infrastructure, and that infrastructure must be set up to have an impact on an organization’s day-to-day operations. Regardless of whether your systems are running in the cloud, virtualized environments, containers or on bare metal, if you still have to configure and provision infrastructure manually, you are moving too slow. Weeks or even days to provision systems means holding up changes that your business needs.

    While automated provisioning has been around for a long time, in 2018 we will see this amplified, primarily due to the ease of use of automation tools and platforms. With automation, infrastructure can be scaled automatically or, using precanned scripts, an operations engineer can quickly affect hundreds or even thousands of devices. This type of technology will allow IT departments to rapidly expand their infrastructure without expanding manpower.

    Once automated provisioning takes over the heavy lifting, focus can move to automating management, maintenance and troubleshooting.

    Microsoft

    Traditionally, in the enterprise, Microsoft environments have been managed by discrete teams. Recently the company has been doing a great job of helping users learn from wider experiences within the industry (joining the open source initiative, for example), and it’s helping break down some of the walls within IT departments. Microsoft also has focused on enabling Azure-backed services in the enterprise, offering more opportunities for customers to adopt automation.

    With SQL Server accelerating in popularity—helped by installs on Red Hat Enterprise Linux as well the traditional base of Windows—automation is an opportunity to ease some of the traditional burdens of scale. We’re already seeing open source development of SQL Server Ansible modules, which is only going to help fit this piece of critical application infrastructure into DevOps-style workflows.

    Microsoft has also taken a broader interest in open source projects. This has included contributing to the Ansible community, helping users integrate open source projects with their Windows environments.

    Security

    Make anything simpler and easier and it is far more likely to be adopted. Over the last 25 years, the connection of our lives to the internet has only increased complexity. This complexity has made it more difficult for security professionals to keep us all safe.

    With configuration management, we’re able to build security in from the start rather than as an afterthought. Changes can be logged and enacted rapidly, giving us the ability to respond to incidents in a timely manner—even across massive scale.

    As our colleagues in cloud and networks have automated more, they’ve reached new levels of scalability. This year we’re already seeing growth of the DevSecOps movement, and expect it to continue. When we bring systems and processes together with automation, doing so securely becomes easier.

    Orchestration

    It comes as a surprise to no one when we say modern applications are complex. They comprise the latest technologies as well as legacy systems. They run in the cloud, across multiple databases and need to be accessed from a variety of devices. This makes it exponentially harder to determine root causes of issues, let alone tell these resources what to do. Since application performance can impact a company’s bottom line, maintaining it is a top priority. However, performance tuning often can’t be an IT team’s full-time job.

    Orchestration is the automation of processes. It delivers relief from the administration, monitoring and help-desk chores that eat up time and resources. IT teams can define how an application is supposed to behave in its running state, and orchestration can bring about that bigger picture. Orchestrated automation is what will really set companies apart from one another, allowing teams to deploy applications quickly and reliably with an easy maintenance path ahead.

    — Justin Nemmers

  • Quality Culture, DevOps Forge Better Connections Between IT, Lines of Business

    Quality Culture, DevOps Forge Better Connections Between IT, Lines of Business

    The automation of software development does not obviate the need for a collaboration between IT and the lines of business, or the development of a culture of quality on the part of the development team. Achieving that quality culture requires more than a change in mindset as developers seek to align quality with the speed and automation goals of DevOps.

    There are five items required for a quality-driven DevOps environment:

    1. Understanding the proper role of “minimum viable product”
    2. Collaboration between IT and lines of business
    3. Having metrics in place
    4. Across-the-board buy-in

    “Quality culture is characterized by employees who are motivated to consistently strive for the highest level of quality,” said Al Riles, principal consultant at Tunnell Consulting, a firm providing solutions to the complex problems faced by life sciences and biopharma companies. “That’s one key component of it, as well as the ongoing process of continuous improvement.”

    Minimum Viable Product and Continuous Quality

    Aligning quality with the speed and automation goals of DevOps is critical to success, and part of this is gaining a deeper understanding of the role of “minimum viable product” and understanding when that approach contributes to the development process.

    “The concept of ‘minimum viable product’ does not, as its name would suggest, contribute to a substandard product,” said C.R. Venkatesh, CEO of Dot Com Infoway, a CMMI Level 3 IT company. “Quite the contrary, the concept is the basis of continuous and iterative improvement, and encourages the use of user feedback, which often results in insights that might be missed by the in-house team.”

    The concept of quality culture and MVP are not mutually exclusive in a DevOps environment, so long as continuous improvement is part of the equation.

    Collaboration Between IT and Lines of Business

    The collaboration that is a key part of DevOps is also a key part of quality culture. “You have a culture in place where everyone embraces that fabric that includes the right type of behaviors and the right values, including communication, reward and recognition, as well as clarity on roles and responsibilities,” said Riles. “That working fabric gets well-defined, because everyone is functioning around the same key elements that constitute that strong corporate culture.”

    “Collaboration has always been important in a DevOps environment,” said Venkatesh. “But we need to define precisely where that collaboration exists. In an internal environment, that collaboration is between IT and lines of business. Increasingly though, IT and development is an outsourced function, and in such cases, that collaboration must be preserved. What this means is that it exists not just within the confines of the outsourcing provider, but also between the provider and the client. The developer must seek out alliances not only with the client’s sourcing manager, but also with other internal stakeholders in the project.”

    If You Don’t Measure, it Doesn’t Exist

    Quality initiatives require an active role in changing the mindset of all stakeholders, but mindset alone won’t get the job done. Metrics must be in place and tied to those quality initiatives. “Even in the smallest of development projects, defined quality metrics must be set ahead of time, with clearly defined outcomes,” said Venkatesh. “By asking what we hope to accomplish with a development project, clearly defining the goals and adhering to a set of predefined quality standards, developers—whether in-house or third-party—are able to accurately predict what the outcome will be.”

    Riles’ process involves a quality management maturity grid, which identifies multiple dashboards. “It allows the organization to become familiar with what a quality organization consists of, and then you can use this maturity grid to measure where the organization is once you embrace this initiative. Then, you can implement the initiative, and come back and re-evaluate yourself to see the progress you’ve made,” said Riles.

    Everybody Has a Seat at the Table

    Incentivizing all stakeholders, throughout every level of the company, is paramount and, according to Riles, “It has to do with communicating what the vision is, and having a clear quality message that’s coming from leadership. Then, there has to be a shared quality mindset among all staff.” Riles notes that the quality mindset is shared by everyone in terms of understanding the organization’s objectives, policies and procedures and their roles in hoping to achieve them.

    This is reinforced by leadership at all levels, who are actively engaged in supporting the development of a quality culture, and they engage and motivate others to do the same. For it to be sustainable, we realize that success is based on the sum of all parts of the organization. They must be continuously monitored and fine-tuned as the organization grows, and this includes communication, reward and recognition, and engagement.

    About the Author / Dan Blacharski

    Dan Blacharski is a thought leader, advisor, industry observer and PR counsel to several Internet startups, and author of the book “Born in the Cloud Marketing: Transformative Strategies for the Next Generation of Cloud-Based Businesses.” He has been widely published on diverse subjects relating to cloud computing and technology, and he is editor of BoozeHub.com. He lives in South Bend, Indiana with his wife Charoenkwan and their Boston Terrier, Ling Ba.

  • New Relic Tracing Software Pinpoints Source of IT Issues

    New Relic Tracing Software Pinpoints Source of IT Issues

    At a FutureStack 2017 conference this week, New Relic previewed an implementation of distributed tracing software that has the potential to close the war rooms where IT operations assign blame for application failure.

    New Relic CEO Lew Cirne says a Distributed Tracing capability that New Relic previewed this week will enable developers or IT operations teams to pinpoint the precise source of any given performance issue. Rather than wasting hours on root cause analysis, Cirne says DevOps teams will now be armed with dashboard they can navigate to visually inspect what elements of a distributed computing environment are specifically affecting their applications.

    Based on the open-source Open Tracing software being advanced by the Cloud Native Computing Foundation (CNCF), Cirne says New Relic opted to embrace an open initiative that should lead to more actionable intelligence being derived from the data New Relic collects.

    At this juncture, Cirne contends that deploying an application in production that has not been instrumented borders on the criminal. He concedes, however, the preponderance of applications deployed in production environments today are not instrumented largely because the total cost of instrumenting legacy applications has been cost-prohibitive. But as IT monitoring software becomes less expensive to invoke using agents that communicate back to a software-as-a-service (SaaS) application, most new applications being deployed in the cloud are now being instrumented.

    To help further that goal, New Relic this week also announced support for .Net Core 2.0 framework recently made available on Microsoft Azure and added support for six additional Amazon Web Services (AWS) services. New Relic now supports a total of 25 AWS services.

    At the conference Cirne also showed how IT organizations can now invoke New Relic application programming interfaces (APIs) to spin up a dashboard to track specific events associated with, for example, the rollout of a new application.

    Access to the data New Relic surfaces, notes Cirne, in turn helps fuel adoption of DevOps because organizations gain confidence in their ability to more rapidly build and deploy applications. That confidence will only increase as IT organizations avail themselves of artificial intelligence (AI) software in the form of machine learning and, soon, deep learning algorithms to make more reliable decisions based on patterns in their IT environments. New Relic, he adds, is able to fuel those algorithms because the service collects 1.5 billion metrics and events every minute. That said, humans will still be required to manage the overall IT environment.

    Cirne maintains that the best way to collect all that data is to employ agents, noting New Relic is adopting those agents to make them lightweight enough to even deploy on microservices based on containers.

    New Relic naturally is not the only provider of IT monitoring tools investing heavily in advanced algorithms. In the not-too-distant future, it’s probable that algorithms deployed by different vendors will share insights with one another. In the meantime, IT administrators can take some comfort in the fact that it should soon become easier to manage IT at scale.

    — Mike Vizard

  • Redefining NoOps to Better Inform IT Decision-Making

    Redefining NoOps to Better Inform IT Decision-Making

    It is safe to say that since the term NoOps escaped from its confines as an assembly language instruction (NOP or NOOP mnemonic for no operation) and in microelectronics (NoOps or null instructions inserted into pipeline, creating bubbles*) into enterprise IT, it has caused more than its fair share of consternation and controversy in the DevOps community. This is hardly surprising, when some of the more prominent claims for NoOps placed emphasis on ending operations entirely, threatening the jobs and livelihoods of thousands of knowledge workers. As with previous movements for automation, NoOps came under immediate attack—and, somewhat ironically, the criticism came from IT industry workers. For better or worse, IT has more than its fair share of hyperbole, religiosity and grandstanding, with the NoOps debate being no exception.

    As someone who started his technology career as a developer, moved into infrastructure and is now accountable for resources being allocated to IT, I find the debate does little to inform my decision-making. In this article I want to share my definition of NoOps with the broader community to clear path for greater adoption of NoOps principles among the DevOps community. I see both of these communities as being distinct and yet highly complementary, as long as our ultimate goal is to generate value for the organizations we choose to work for and, by extension, the customers which they serve.

    NoOps as an Ideological Principle

    Various definitions of DevOps have been refined and become more stable over time. I don’t believe it would be particularly controversial to recognize DevOps as a culture, a methodology for creating high-quality applications and delivering them into production in the most efficient manner. In my book, “NoDev NoOps NoIT,” I choose to define NoOps as a guiding principle that makes assertions to help IT decision-makers inform their decisions. It is more useful to separate our notions of DevOps and NoOps into methodological and ideological categories, because doing so strengthens our understanding of both terms and equips us to make better IT decisions.

    Before we examine the assertions made by the NoOps principle, I want clarify why I have rejected other definitions of NoOps and critiques of NoOps itself.

    NoOps Spells the End of Operations

    One of the most common and enduring uses of the word “NoOps” is to refer to eliminating IT operations entirely. The problem with such definitions is that they conveniently scope IT operations in a manner that allows them to be eliminated. IT operations roles are not static in the face of changing technology; arguably, they evolve more rapidly than application roles. The original activities of racking, stacking, cabling and administering IT infrastructures in a typical enterprise has been hugely diminished by outsourcing, commoditization and the advent of cloud infrastructure. However, new activities in software development life cycle, automated provisioning, monitoring, metering and security have created new roles for infrastructure/operations developers. NoOps is not about eliminating IT operations; rather, it is concerned with maximizing automation in IT operations.

    NoOps is the Evolution of DevOps

    While superficially it may well seem that NoOps takes DevOps to its logical conclusion, this line of thinking chooses to ignore the huge swath of DevOps methodology that does not overlap with the automation of operations or the fact that DevOps is itself an evolving methodology. I simply don’t find this definition to be particularly useful in day-to-day decision-making. At best, it’s a dimly lit observation.

    DevOps is NoOps—NoOps is Just a Confusing Term

    The idea of NoOps is an expression of the benefits of automation. How we choose to define the term will dictate its utility. If we choose to define it in a fashion that leads to confusion, then fault lies with the definition and not with the idea itself, which I believe is a powerful one that should not be ignored. Attempting to simply define away NoOps is as wrong-headed as stating that NoOps is the end of operations. Overloading DevOps methodology to encompass NoOps ideology stretches the definition of DevOps beyond its useful boundaries.

    NoOps Assertions: Eliminate All Manual Intervention in IT Operations

    Eliminating manual intervention in IT operations is a fundamental assertion of NoOps. This assertion is made from an understanding of the benefits of the automation and the observation that the very tools we use in IT—computers—were invented to automate conative and algorithmic processes.

    While we may never be able to fully automate every aspect of our operations—for example, some regulators demand four-eyes processes for approval and execution—we must rigorously challenge the unthinking orthodoxy that currently governs many IT processes.

    Automate, simplify and standardize: I subscribe to this mantra but one has to proceed in the right order; that is, simplify, standardize and then automate. Otherwise, you literally risk making an ASS out of your IT automation efforts.

    I can say with a high degree of certainty that any failure to automate a process could probably be traced back having made no attempt to simplify the process before automating it. No attempt was made to challenge the process, to question who is doing what and why before automating it. Indeed, no effort, was made to question the existence of the process in the first instance.

    Once a process has been simplified, standardizing it follows almost naturally. Stakeholders adopt your process because it is simple, it saves them time and generates value for them.

    The opposite is also true: A poorly thought-out, complex process will never win buy-in from users. Any attempt to put lipstick on such a pig will be fraught difficulty, often resulting in the vast majority of users and stakeholders finding exceptions to your attempts to increase adoption of the offending process. 

    NoOps Assertions: Eliminate All Dependencies Between Application Developers and Infrastructure/Operations Developers

    As the trend toward software-defined everything matures, we need to change our organizational structure to adapt with the new landscape. Within enterprise IT, the war between application and operation teams is over, even if there are still combatants that don’t realize that the application teams won. In the software-defined paradigm we are all developers. Application developers write business/end user logic and infrastructure/operations developers write run-book instructions using the tools and APIs made available to them by infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) vendors. Both of these types of developers write code and we find more and more frequently it is the same individuals writing both application and infrastructure code; hence, the rise of the full stack developer and the full spectrum technologist.

    As a CTO I organize my technology division into three teams: Application Development, Infrastructure Development and User Experience Development. These teams are physically situated next to each other and work toward a single technology strategy defined by a NoOps ideology and DevOps methodology.

    In Summary

    When we are presented with ideas that are threatening and challenge fundamental elements of our existence, such as the way we work, the best response is to seek out opportunities presented by those ideas and adapt to them. For the DevOps community, the first step in engaging with NoOps is to accept the ideology is based on a very real and powerful foundation of automation. As a community we can choose to dismiss NoOps or we can choose to embrace the possibilities it offers and allow it to enrich DevOps methodology. I would posit that those among in the DevOps community who can adapt to a NoOps reality will not only survive but thrive.

    About the Author / Hussein Badakhchani

    Hussein Badakhchani is a Distinguished Technologist and author with over 20 years of professional experience in financial services technology. Having worked for institutions such as the Bankers Automated Clearing System (BACS), Deutsche Bank and VocaLink – MasterCard, Hussein has a proven track record of delivery in some of the most competitive global capital markets. As a trusted academic, practitioner and adviser, Hussein also provides critical analysis of technology to executive and investment decision makers in government, banking, financial, commercial and defense sectors. He is the author of “NoDev NoOps NoIT,” principles governing the ideology, methodology and praxeology of informed IT decision-making. Connect with him on LinkedIn.

    *”Microelectronics,” by Jerry C. Whitaker.

  • 9 Essential Ingredients for Modern Enterprise Applications

    9 Essential Ingredients for Modern Enterprise Applications

    Digital transformation. It’s the latest in a series of buzz phrases intended to describe how enterprises are embarking on top-to-bottom modernization of their IT environments. It’s easy to see why it’s a hot topic. Emerging technologies including cloud, containers, microservices and distributed applications hold the promise of greater flexibility, lower cost and faster release cycles. The benefits to companies that make this journey can be enormous.

    Unfortunately, making this journey can take years with today’s manual processes and antiquated tools. Not to mention that most IT budgets are at least 80 percent focused on keeping the lights on. Application modernization projects can be extremely complicated since legacy, monolithic enterprise applications are intrinsically dependent on underlying infrastructure and data stores. Cloning complex application environments, including critical production data, for upgrades or testing often can take days or weeks, slowing down cycles and contributing to lower quality releases. Even new applications are too often designed with infrastructure dependencies, trapping organizations onto specific cloud, server or container vendors. This vendor lock-in reduces choice and leaves IT organizations open to unexpected price hikes down the road.

    The truth is that the way we have designed, built, deployed and managed enterprise applications needs to change. Business-critical software is too often built in monolithic blocks that are nearly impossible to move to new infrastructure or storage options without lots of effort and time. The applications are hard to upgrade since updating even one small portion means rebuilding and retesting the entire thing. Managing the various versions of the discrete application modules and the resulting testing permutations can be quite challenging. It’s not unusual to hear from CIOs that they feel trapped in a world where they can only reasonably expect to update critical enterprise applications just twice a year at most.

    Business needs to move faster. There’s no reason why release cycles, even for enterprise applications, couldn’t be every few days instead of months. Application quality should actually be better in this world. Continuous delivery models such as DevOps should be an integral part of the process. And security should not be an afterthought; it should be built-in. To accomplish this, the future of enterprise applications must look very different from today.

    What are the essential ingredients for modern enterprise application platforms and tools in this new world? Here are a few suggestions.

    Complete Portability, Without Code Change

    Enterprise applications must be abstracted and separated from any dependency on underlying infrastructure, including sources of data. By abstracting the functions of an application into components that can run anywhere, it’s possible to then move the application to different infrastructure combinations, without changing a single line of code. It’s only through complete portability between cloud environments, container tools and servers that IT organizations will break vendor lock-in and gain the flexibility required to move their applications to vendors that offer the best combination of price, performance, reliability and features.

    On-Demand

    All enterprise applications should be on-demand, meaning the provisioning of new instances should be hands-free and fully automated. This implies tight integration with orchestration tools that most companies are already using to provision infrastructure. The key difference here is that the provisioning of storage options also needs to be fully automated. This is made possible by the fact that modern applications won’t have any dependencies on the specific data stores they rely on. This on-demand nature is not restricted to technical teams but includes business users that can easily perform user acceptance testing by simply provisioning full-fledged application environments.

    Self-Healing

    Modern enterprise applications should be self-healing, which means applications not only should have measurable data points to define their health but can then react based on these metrics. They must be able to scale up (or down) based on performance characteristics up to a certain cost threshold, restart on a healthy node in case of infrastructure bottlenecks and cache or deploy closer to the user based on latent use performance.

    Composable (DevOps-friendly)

    All enterprise applications should consist of a number of building blocks: APIs, web servers with content, databases seeded with data, security policies, the operating system, network configurations, deployment configurations and application binaries. By breaking apart monolithic enterprise applications into smaller components that can then act as independent services, IT organizations gain the flexibility to upgrade and automatically deploy individual components through standard DevOps processes and orchestration tools. The services can run anywhere desired, giving flexibility of choice in infrastructure or sources of data. And developers can use a point-and-click UI to pull pre-defined components together to build larger functions of an application.

    Model, Snapshot and Clone

    Once an application is separated into its essential components, a catalog can be maintained that makes it easy to create new versions of the application. Developers, test engineers and DevOps teams can then pick and choose whatever combinations of components they need to create or clone complex application environments for testing or deployment. The state of the application environments can be snapshotted, cloned and replicated. This cloning process should be efficient and quick. This dramatically speeds up development and testing processes, which to-date have been largely manual.

    Scalable

    Scaling application and infrastructure environments automatically, on-demand, and in near real-time is one of the essential capabilities that makes modern infrastructure so valuable. Any solution that is used to develop, test, deploy and manage enterprise applications should offer these same capabilities, giving the ultimate in cost flexibility, performance and scalability. As containers are moving quickly from the lab into production environments, look for a container-based solution that complements this strategy.

    Security is Included

    Application security should not be tacked on after deployment. This slows down continuous delivery processes like DevOps and creates friction between development/ops and the security team. Instead, security should be considered an essential component of the overall application environment and treated the same as any other component and baked into the application from the start.

    Push-Button Upgrades

    Upgrading enterprise applications should be made much easier by taking a point-and-click, push-button approach through a modern UI and integration with continuous deployment tools. Once an application is blueprinted into its various components, using a modern UI to choose versions and assemble the final application becomes entirely possible, saving time and reducing manual errors.

    Single-Pane-of-Glass Application Management

    By taking an end-to-end view of the enterprise application development, testing, deployment and management process, it’s now possible to create a “single pane of glass” console that gives development and deployment teams a powerful way to manage what’s been deployed to various infrastructures in the organization. With this approach, it’s also now possible to collect invaluable utilization and cost metrics which can help an IT organization continuously improve their portfolio.

    Enterprise applications of the future are going to look very different from today’s monolithic behemoths. By leveraging new technologies and processes, IT organizations will be able to dramatically speed up their modernization efforts and release cycles, improving competitive position. The inherent cost savings of this approach will be transformational as well, as IT budgets shift toward net-new innovation, not just keeping the lights on. The future looks bright indeed.

    About the Author / Rahul Ravulur

    Rahul Ravulur is the cofounder and CEO of appOrbit, which was founded in 2014. Most recently, he was the Director of Product Management at VMware managing the Availability suite of products. Before that, Rahul managed the vCenter Server and Client set of products with a special focus on scalability and extensibility to chart the evolution of vCenter to a broad virtualization management platform. Prior to VMware, Rahul held engineering leadership roles at BMC Software and Marimba.