devopsy.kinsta.cloud

Category: Features

  • AIOps: Supporting Reliability at DevOps Speeds

    AIOps: Supporting Reliability at DevOps Speeds

    AIOps looms large as a way to help push the DevOps envelope. How can organizations prepare?

    As organizations journey down the path of DevOps maturation, sustainable IT operations and IT service management remains a challenge for many. Even advanced organizations that have managed to speed up deployment rates and improve software quality struggle to maintain the resilience of the infrastructure that supports those applications. To support DevOps speeds, a growing number of organizations are turning to AIOps—the use of artificial intelligence (AI) and machine learning in IT ops—to speed up analysis of IT problems and better automate incident handling.

    A new study out this week from OpsRamp shows that ops pros are able to reduce mean-time-to-resolution of incidents by as much as 50% through the use of AIOps. The use of AIOps is still infrequent, but analysts say its prevalence will grow quickly. Gartner says about 5% of organizations were using AIOps tools last year, but that by 2023 the deployment rate will shoot up to 23%.

    But as DevOps teams lean on AIOps tools, management will need to harness a new set of skills to get the most out of the types of operational automation AIOps will afford. In the coming years, experts believe AIOps will change the complexion of the IT ops workforce. Fewer people will be needed in the network operations center (NOC) to manually sift through alerts and respond immediately to incidents. More people will be needed to curate data, scrub it and train the algorithms that will do the heavy lifting of event correlation and determining the root cause of problems.

    As organizations and individuals plan out how they’re going to future-proof themselves for the changes in IT ops wrought by AIOps, experts say they should increasingly see the need for the following three roles in IT organizations.

    AIOps Architects

    Expect to see more job postings in the near future looking for AIOps architects and automation path designers, said Will Cappelli, CTO of Moogsoft and the former Gartner analyst who’s known for coining the term AIOps.

    “(AIOps architect is) essentially a software development job involving the construction of meta-algorithms that guide the flow of control of the AIOps systems,” Cappelli said.

    Potentially falling in this umbrella could be roles such as machine learning and AI designers that focus on designing the algorithms themselves, and interaction designers that focus on designing the automated workflows. According to Brendan Caulfield, co-founder of ServerCentral Turing Group, these roles already exist in other business capacities. With AIOps, these design jobs will start to be applied specifically to IT operations as well.

    To prepare, veteran IT ops experts should start thinking about how they can bolster their skills, and management need to recruit and train accordingly.

    “Mathematics and an end-to-end understanding of how modern IT systems behave will be critical,” Cappelli said.

    ITOps Data Scientists

    AI depends upon good, clean data and sound modeling to work effectively.

    “The most sophisticated and expensive AI tools are useless if a company isn’t able to feed them with a high volume of high-quality data, in a format the system can digest,” said Rajesh Kalidindi, CEO of Leva Data.

    This was corroborated by the OpsRamp report released this week that showed maintaining data accuracy is the No. 1 challenge cited by organizations deploying AIOps today. Many organizations will need ITOps specific data scientists to attend to this problem.

    “Building high-volume, high-quality data sets will be increasingly important, and it requires a lot of human effort,” Kalidindi said. “AI has a long way to go before catching up with human reasoning (let alone surpassing it), and it can’t make any progress without people developing data models for AI to work with.”

    Augmented Intelligence Analysts

    According to Caulfield, algorithm training and support by domain experts in operations will become increasingly important at most organizations.

    “No matter how ‘smart’ an algorithm is, or how well its designed, there will be exceptions that are unique to a business that will need oversight and tuning,” he said.

    Kalidindi concurred that human intervention will be needed for a long time to augment and validate the insights and actions driven by AIOps, noting that this will lead to the rise of a new role for ops analysts.

    “Especially in the early days of machine learning, humans are needed to judge whether an algorithm is leading to the right judgment,” he said. “For example, if we were to apply AI to analyzing the problems the IT Help Desk encounters, a human would be needed to judge whether the algorithm made an appropriate recommendation. If not, IT and data science needs to work with the human’s recommendation to better train the AI model on how to handle that problem in the future.”

    One thing that most experts agree about is that the rise of AIOps will not diminish the need for IT pros. In fact, they say that domain expertise will be more important than ever. However, it will need to be bolstered by additional knowledge of data science, how AI works, and systems architecture.

    “They need to retool themselves from admin-oriented activities to scripting/reporting-oriented tasks, and they need to be more application aware than ever before as infrastructure becomes a commodity,” said Ravi Raghavenderrao, vice president of service delivery at NetEnrich, of IT ops professionals in an AI-enabled future.

    To those who have adjusted to DevOps transformations, this should all sound very familiar.

    — Ericka Chickowski

  • Digital Transformation: Digitally Resilient Organizations

    Digital Transformation: Digitally Resilient Organizations

    While some are growing weary of the term “digital transformation,” the reality is, it’s here to stay. Digital transformation isn’t just a buzzword or a transient phenomenon. Enterprises are digitizing themselves as rapidly as they can and automating what can be automated, improving customer experiences, leveraging data for machine learning and improving customer experiences.

    These levels of transformation are underway across vertical industries—manufacturing, retail, transportation, health care, telecommunications and government. Research firm IDC, expects worldwide spending on digital transformation products and services to reach $1.8 trillion in 2019, a rise of 18% from 2018. IDC expects that figure to rise to more than $6 trillion over the next four years.

    “Strong DX technology investment growth is forecast across all sectors, ranging between 15% and 20%, with the financial sector forecast to be the fastest with a compound annual growth rate (CAGR) of 20.4% between 2017 and 2022,” said Eileen Smith, program vice president with IDC’s Customer Insights and Analysis group.

    The two industries that will invest the most, according to IDC, are expected to be discrete manufacturing, at $222 billion, and process manufacturing, at $125 billion. IDC said the top priority is smart manufacturing, supported by significant investments in autonomic operations, manufacturing operations and quality. Retail will follow closely behind, which in turn will be followed closely by transportation and professional services.

    As hard as it may be to believe, the four pillars of transformation—DevOps, cloud, AI and IoT—are still in the nascent stage of deployment. The most popular digital transformation use cases this year, according to IDC, will be freight management ($60 billion), autonomic operations ($54 billion), robotic manufacturing ($46 billion) and intelligent and predictive grid management for electricity, gas and water ($45 billion). Additional use cases that will see investments higher than $20 billion in 2019 include root cause, self-healing assets and automated maintenance, and quality and compliance.

    Those organizations that excel in their digital transformation efforts will find that they’ll reap tremendous benefits. However, excellence here isn’t about short-term wins or one-off projects. Excellence in digital transformations is about properly tooling the enterprise for digitization so that the organization is as productive as it can be, cost-efficient and technically agile enough to seize new business opportunities as they arise and successfully endure or even thrive through market, geopolitical or other adversity. It’s about building an iterative, generative, agile digital platform that positions the business for long-term success. This is digital resiliency.

    Most enterprises aren’t close; according to the 2018 Global CIO Survey from Deloitte, about 70% of the 1,400 executives they surveyed don’t even have a digital enterprise strategy.

    The digitally resilient enterprise has built a business-technology platform that is elastic and agile and can position itself correctly depending on current business demands; it’s reasonably secure from cyberattacks that threaten data. The digitally resilient organization is also continually learning from its data and making adjustments as markets, its workforce and its customers demand. The digitally resilient organization has eliminated the bulk of its technical debt, and it innovates, so competitors don’t disrupt it with a better idea, execution and understanding for what customers want.

    In the weeks and months ahead, I’ll be sharing more stories, case studies and insights on how organizations can build the digitally resilient organization that positions them for success over the long term.

    — George V. Hulme

  • Mainframes: The Cloud Before the Cloud

    Mainframes: The Cloud Before the Cloud

    Here’s something to think about: Despite the fact that IBM stopped manufacturing personal computers in 2005, deciding instead to focus on higher margin business services, the company continues to produce mainframes and by all estimates will continue manufacturing them well into the future. The question is, why? The answer: because there is still significant demand for this type of hardware.

    The fact is that a mainframe is a monster when it comes to computation and processing transactions. One mainframe can process 2.5 billion transactions daily. That’s the equivalent of 100 Cyber Mondays in a single day. To give you a clearer idea of the immensity of scale, keep in mind that Cyber Monday sales in 2018 were $7.9 billion. This translates into a mainframe being able to handle a bit more than three-quarters of a trillion dollars in transactions each day, which is almost twice the yearly GDP of Austria!

    As I said, the mainframe is a workhorse. Yet, its power and potential are hidden from most people who work in the modern cloud. This is surprising because there’s a good argument to be made that, given its power and scalability, coupled with its support for a large number of concurrent users, the mainframe was the cloud before there ever was a cloud. However, the technology is practically unknown among younger developers, mostly due to cultural reasons and a lack of historical awareness. That more people are not taking advantage of the tremendous opportunities at hand is a misfortune. When it comes to mainframe computing, there’s a lot of interesting tech to be learned and a good amount of money to be made. It’s just a matter of increasing awareness to do this. A good place to start is to redefine the narrative.

    Allow me to elaborate.

    A Special Club

    When mainframes appeared on the commercial landscape, few people interacted with computers and even fewer worked with them directly as programmers or system administrators. Just as in a modern data center, the machines were isolated in climate-controlled rooms to which few had access. Access to the actual physical machine was restricted to a special few. But unlike today, when restricted access is due more to security concerns because there are a lot more people around who are potential black hats, back then access was also restricted due to the exclusivity of the profession.

    In the 1950s, 1960s and well into the 1970s, not just anybody could program or be a systems administrator. You could go to a technical school to learn to become a computer operator, which meant you could work at a terminal as a bank teller or travel agent. Or you could learn to become a data processing clerk and work in a back office at a brokerage firm. But to learn to program, you had to go to college. Then after college, you had to go to work for a company or organization that actually used computers in day-to-day operations. These were banks, insurance companies, major manufacturers such as General Motors and General Electric, airlines, very large retailers and government. Computing was a club and you had to be well-educated to get in and be well-liked by the organization to keep your membership. Yes, there were the outliers—Gates, Allen, Joy, Wozniak and Jobs—but for most people, the career path to being a programmer was college and then into big business or government.

    As a result, computing had an air of mystery and magic to it. Remember, until the mid-1980s, most people had never touched a computer. It was the stuff of moon landings and election night predictions on network TV. Then the PC came along and changed everything. Within 10 years computers became commonplace. Even elementary schools had them—at least, those that had the budget and foresight. The power that business applications such as the spreadsheet program Lotus 1-2-3 brought to small business motivated even the dry cleaner on Main Street to plunk down the thousands of dollars it cost to buy a PC. The productivity boost was worth it. Also, since the dry cleaner actually owned the machine, the dry cleaner’s kid could learn to program on the box unencumbered, when it wasn’t being used during business hours. Remember, the Microsoft DOS operating system that shipped on every IBM-compatible PC came bundled with the programming language BASIC. You didn’t need to go to college to learn to program; all you needed was a book.

    So, PC programming took off. Instead of having to go through the effort required to get into the special club the mainframe programmers belonged to, PC programmers started their own clubs and anybody could get in. All you had to do was show up. PC programming became a meritocracy. Also, it became extremely lucrative work. There were a lot of PCs being shipped and the appetite for applications to run on them was enormous. The unlikeliest of people, such as Lotus Software founder Mitch Kapor and his sidekick, Grateful Dead lyricist John Perry Barlow, became wealthy, thanks to the PC.

    The PC became cool and programming for it became cooler. But there was a fact that got obscured as the popularity of the personal computer grew: Compared to the mainframe, the PC was a toy—a productive toy, a liberating toy, but a toy nonetheless, very much in the same way that a go-kart is a toy compared to a Formula One race car.

    Feature for feature, the mainframe ate the personal computer’s lunch. The IBM System/370 Extended Architecture Mainframe released in 1983 was a 31-bit machine that could support up to 8MB of memory with a processor running at 38 MHz. By comparison, the IBM PC-XT, also released in 1983, was an 8-bit machine that shipped with 128KB of RAM and an 8088 processor that ran at a speed of 4.77 MHz.

    But, as the saying goes, “You should never underestimate the value of cool,” and the PC was very cool. It got a lot of attention while the mainframe stayed hidden away in climate-controlled rooms in the basements of banks and insurance companies. Yet, the mainframe was more powerful, and whereas the PC was meant to meet the needs of a single user, a mainframe can service thousands.

    Built to Scale Built from Inception

    Mainframe computers from the start were designed to support hundreds (if not thousands) of users. However, more importantly, mainframes were and are designed to support millions of concurrent transactions. When you think about it, while it’s possible for a high number of user requests to exhaust CPU utilization in a typical commodity machine—which is the reasoning for being able to scale up CPU count by increasing VM allocation in the cloud-based computing cluster—the real burden on the CPU is not so much the request count but the computing burden that each request incurs. For example, one request getting a .JPG of a cat will incur nowhere as much burden as a request that needs to convert an audio file in .WAV format to MP3.

    The need to alleviate request burden has been around since bank tellers working in the various branches of a big bank had to make deposits and withdrawals at the same time. Mainframe engineers addressed the problem decades ago. Technologies such as batch processing and message queues, which make computational activity asynchronous and are optimized to fully utilize CPU capacity efficiently, were and are commonplace in the mainframe landscape.

    IBM’s 360 mainframes supported batch processing in its OS/360 system starting in 1964. Batch processing allows thousands of instructions to be performed on terabytes of data at pre-scheduled times (usually “off-hours”), all without human intervention.

    Message queuing allows processes to take data in the form of a message stored in a message queue and perform computational activity according to the data in the message. Processing is performed independent of a request in an asynchronous manner. When processing is complete, a new message is created and sent on to another queue, where another process will do more processing or create a notification indicating that work is complete. IBM MQSeries was an early message-queuing technology first used in 1993 at State Street Bank well before the internet became commonplace.

    The reason that support for user and transactional concurrency was possible in mainframes is due to a technology that is commonplace in today’s cloud environment but was unheard of among PC users back in the days when most data was exchanged between standalone PCs using floppy disks. That technology is virtualization.

    Virtualization Takes Mainframe Computing to the Next Level

    Today we take virtualization—the capability to have software simulate hardware—for granted. Without it, we couldn’t have native cloud providers such as Amazon Web Services, Google Cloud and Microsoft Azure. These services rely on virtualization to provide the segmentation and computational isolation required to meet the needs of the modern computing. Yet, as essential as virtualization is in the world of commodity cloud computing, putting a layer of virtual machines on a commodity PC is a fairly recent event in the history of computing. VMWare, VirtualBox and KVM became mainstream in the mid-2000s. On the other hand, virtualization has been part of mainframe technologies since the mid-1960s. Virtual memory appeared in the mainframe in 1965. Machine virtualization was introduced on the IBM 370 mainframe in 1972 and is still an important part of the mainframe computing experience today.

    Every single person who logs onto the mainframe when working in a native mainframe operating system gets an identical address space. You can think of each address space as a standalone virtual mainframe system. These address spaces are created instantly and are protected from interfering with each other. Also, many companies create logical partitions of their hardware called LPARs (logical partitions). The logical partitions are controlled by a native firmware hypervisor called PR/SM (pronounced Prism).

    The value that LPARS provide is a further separation between environments. This means not only can you separate users, but you can also create distinct computing environments such as those created when virtualizing X86 machines. For example, you can have a shared development environment as well as environments for testing, staging and production. You can allocate resources and security access to a particular environment based on need, just like you would in a data center full of commodity machines. This means you can configure production systems to be more secure and have higher execution priority and more resources such as memory. In fact, according to the U.S. government, from a security perspective, virtual machines created on the mainframe are considered distinctly separate machines.

    LPARs running on the same hardware or different hardware under the native mainframe z/OS operating system can be linked together as a Sysplex for redundancy and to easily provide additional capacity. Dynamic Virtual IP Addressing (DVIPA) is used to dynamically route IP traffic across multiple LPARs in a Sysplex. This is analogous to being able to tie together a variety of web servers behind a load balancer or organize them within a Kubernetes cluster. Being able to tie computers together is an important feature for making systems scalable. Also, linking computers across geographic regions increases performance. It’s always faster to work with a machine that’s closer to you than one that’s further away. As mentioned earlier, being able to scale systems up and down is a key feature of cloud-based computing. Dynamic connection, which is part of mainframe architecture, is critical for scaling to work.

    The important thing to understand is that the stuff we consider to be modern in terms of the machine virtualization that we rely upon to make the cloud work has been in play for years on the mainframe. Also, virtualization on the mainframe makes it possible for programmers and system administration staff to work in a variety of operating systems and programming languages as we’ve come to expect in commodity cloud instances. Machine virtualization allows mainframes to support Linux. Whether the computing environment is virtualized Linux or native mainframe, developers can code in Java, C/C++, Python, Perl and a variety of other languages, including something as new as Swift. But, then again, the mainframe was always intended to support many programming languages.

    Even back in the ’60s and ’70s, programmers could write in COBOL, PL/I, job control language (JCL) and Customer Information Control System (CICS). Also, writing low-level code in Assembler has always been possible. Clearly, the versatility that modern developers enjoy programming in a variety of languages in a cloud environment has been part of mainframe computing for a while. Yet, the benefit has never been at the forefront of developer awareness. Maybe it’s time to change the narrative.

    Changing the Narrative About Mainframe Computing in the Cloud

    As I stated at the beginning of this article, IBM continues to make mainframes because there’s a growing demand for the technology—particularly as smartphones and IoT devices proliferate worldwide. Netflix might be spinning up containers on a commodity machine in a data center to let you view past episodes of “Orange is The New Black.” But when it comes time to pay for your Lyft ride using your iPhone, that credit card transaction will most likely be processed on a mainframe that’s providing service via some sort of API gateway.

    There is little benefit to arguing that mainframes should or can be used interchangeably with commodity servers. That’s like saying a fleet of automobiles can be used interchangeably with a city bus. You can do it, but it doesn’t make much sense. Each technology has benefits that when used together, make the overall transportation system more efficient. The trick is to understand where and how the technologies fit together in the big picture. In this case, the big picture is the cloud.

    The old narrative around mainframe technology is based on perceptions that are no longer applicable. The modern mainframe is no more centralized than the single building that houses a regional data center. In terms of programming languages, mainframes moved beyond FORTRAN and COBOL decades ago. Current mainframe virtualization technology makes it possible to run programs written in just about any programming language. And, mainframe emulators, such as ZD&T, make it possible to get the hands-on experience necessary to get familiar working in a mainframe environment.

    The Perceptions of the Past are No Longer Applicable

    The modern mainframe is a powerful resource that provides extraordinary benefits for cloud computing. The new narrative is that the mainframe is modern, adaptable and well-suited to accommodate a very high volume of transactions at lightning-fast speeds. And, it’s a good way to make good money.

    As the current workforce (which is admittedly aging) approaches retirement, a new breed of mainframe developer will be needed to continue the work of making the mainframe a mission-critical resource in the modern cloud. In addition to understanding the essentials of mainframe computing, these developers will need to be well-versed with the modern tools and techniques that drive cloud computing. It’s an investment that I’ve urged many up-and-coming developers to make.

    Putting It All Together

    Let me share a piece of personal history: A while back I needed to do some programming. So, I went to my desk, logged into my system, wrote some code and ran it. It worked like a charm! I saved my work, finishing up just in time for dinner. A while later, it was again time to program. I went back to my desk, logged into the system and coded away. Just another day of slinging the code, right? Well, not really.

    My first coding session was in 1975. “A while later” is today. Forty-four years have passed. Back then, I was working on a mainframe that was 50 miles away. Today, I logged into an online programming environment that was also miles away, maybe even halfway around the world. That’s how it is with cloud computing: The resources are any way at any time.

    Interestingly, despite the passage of a significant amount of time, my current developer experience is not that different than the one I had decades ago. It’s still just me and a terminal. Back then, the terminal was a screen full of green characters. Today, my terminal is able to accommodate a variety of media and input devices. But, at the other end of the wire, who knows what’s going on? For all I know, I might still be connecting to the same mainframe I used back in 1975. Which is my point.

    Much of what we consider new and wonderful about cloud computing today has actually been around for a while in mainframe technology. In many ways, the mainframe was the cloud before the cloud. And, it’s still a powerful resource for what we have come to know as modern cloud computing. Given its power, versatility, scalability and support for modern DevOps tooling, the mainframe is a perfect resource for today’s and tomorrow’s cloud computing infrastructure. It’s a computing resource that we’ll do well to take advantage of as we move forward in our development efforts on an increasingly connected planet.

    — Bob Reselman

  • Keeping NoOps From Going Rogue

    Keeping NoOps From Going Rogue

    “We’re NoOps—everything is in the cloud and we have no infrastructure to manage.” Before running that victory lap and shifting everyone to the dev side, consider several NoOps risks carefully. I’m really thinking about teams using all-SaaS stacks, especially in martech, edtech and other areas. However, the rise in microservices and serverless means more teams are leaning toward NoOps. At least a few people on your team should always watch for rogue issues on the ops side of the equation.

    Locked-in Vendors

    Risk: Cloud-based tools in the same category rarely have the same functionality. Once one is selected, you’re committed to its specific features. Moving away from a tool may mean dropping a popular application feature or changing workflow with coding to recreate functionality.

    Mitigation: Evaluate unique features and customized data fields carefully before use. Solving data format differences is relatively easy for common fields. Look for tools with well-documented APIs and integrations or connector support for analytics. If there are no integrations out there, that’s a red flag.

    Ghosting

    Risk: Lock-in becomes a big problem if the vendor ghosts. SaaS startups often meet one of two fates: they are acquired or they crash and burn. A tool critical to your workflow may disappear overnight. In the acquisition scenario, you may have some time and support in migrating from your tool to its successor.

    Mitigation: Always have a Plan B for every cloud-based tool in your stack. Competitors are introducing new tools frequently. A trade study done two years ago may be completely obsolete on today’s fast-moving landscape. Proactive migration to newer solutions may reduce vendor risk and improve features.

    Limited Observability

    Risk: Overheard in a conference recently—Those who develop the code are more motivated to build in useful observability for those in operations if those folks are the same team. In NoOps, that’s not in play. If a cloud-based tool in your stack is down frequently or providing strange results, it may be very difficult to tell what is happening. Observability is often replaced by faith that the SaaS vendor has done its job and you aren’t experiencing a corner case it hasn’t tested.

    Mitigation: Observability and monitoring aren’t the same, but when you don’t have observability inside SaaS tools, monitoring helps. Application performance management (APM) tools are emerging with new ways to build instrumentation around microservices. Create test cases with synthetic data to check your functionality—you’ll need these to provide evidence for the vendor in any bug report.

    Unoptimized Workloads

    Risk: You’re also often at the mercy of the SaaS vendor when it comes to speed of results. It’s a common tripping point to pilot a SaaS workflow with a few users and test cases, and then find out it doesn’t scale when everyone is brought in.

    Mitigation: This is one the biggest NoOps risks where ops expertise pays off. Where is the problem, exactly? Application problems may be candidates for workload acceleration—such as running on a GPU (or FPGA) enabled cloud instance. Reporting problems may be better-suited for an analytics tool, which can be run offline with extracted data.

    Tangled Analytics

    Risk: Every SaaS tool reports different metrics in different ways. Worse, users in a multi-cloud environment face learning and visiting multiple applications to look at data. Different applications report similar facts using different terms. As the tool stack and data sets grow, it takes longer and longer to analyze data.

    Mitigation: Dashboards pay off early with one destination for data across the stack. Earlier, I mentioned the need for integrations or connectors—this should be a requirement for tool selection, both in the stack and the analytics tool. Deciding on which KPIs to track in the dashboard also focuses conversation and minimizes digging.

    Closing NoOps Risks

    There’s also the big topic of multi-cloud security and compliance, probably worth a series of posts by themselves. An Ops team working proactively in tool selection can comprehend many security risks before committing to tools and exposure. More value unfolds over time, as the security posture evolves with discovery of new threats.

    The tech pendulum is always swinging. For many organizations, NoOps swings the pendulum a bit too far from DevOps and leaves risks open. A better philosophy is MinOps, where a small team is deployed, watching for and even anticipating problems.

    I’d be interested to hear if you’ve tried NoOps and been successful over time, or if you reverted to a MinOps approach.

    — Don Dingee

  • DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

    DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

    In this DevOps Chat, Jonathan Fries, VP of Engineering and Digital Transformation at Exadel, tells us about the new Innovation Lab by Exadel—a place for organizations to accelerate their transformation. We also talk about the state of IT in general from his perch at Exadel, a company with 20 years of empowering IT.

    You can find out more about the Innovation Lab at exadel.com/innovation-lab/.

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

    Transcript

    Alan Shimel: Hello, everyone, it’s Alan Shimel, DevOps.com, and you’re listening to another DevOps Chat. This episode of DevOps Chat features Jonathan Fries of Exadel. Jonathan, welcome!

    Jonathan Fries: Hi, Alan. It’s great to be here.

    Shimel: Hey, it’s great to have you here, Jonathan, and I wanna thank you. It’s always nice to have a new company coming up on our chats here, so it’s—you know, some fresh blood for the audience. I assume most of our audience is not familiar with Exadel, so why don’t we start with that, Jonathan? Tell us a little bit about Exadel.

    Fries: Sure. So, Exadel is a global software engineering services firm. So, we help our clients write software. We have—we’re a global company, so we have offices in Eastern Europe, Belarus, Lithuania, Poland being kinda the big ones where we have our offices in Europe. And, you know, we help clients in a variety of areas. Probably our big verticals are health care, finance, transportation, media and entertainment, and high tech. And, you know, we have some really good clients in those areas. Health care, McKesson is one that people have heard of. Finance, we work with Deloitte. In the high tech world, we have HP and Google as our clients.

    So, we’re doing offshore development for a lot of it. We have teams that are either all in Europe or usually a hybrid of some people here in the U.S. and some people in Europe. We’ve got about a thousand developers in Europe, so that’s where a lot of our work gets done. We’ve been around for 20 years, and so yeah, that’s a bit about Exadel.

    Shimel: Another overnight sensation, huh?

    Fries: Pardon?

    Shimel: I said another overnight sensation.

    Fries: [Laughter] Yeah, it’s been a gradual sort of buildup of working with clients and, you know, getting to work with a lot of interesting companies and them recommending us to others.

    The name of the company actually comes from a combination of excellent and delivery. I always think that that’s an interesting fact to bring up, and I think it’s an important part about kind of who we are and where we come from and how we got that list of clients. You know, we’re all about building really great products, software products for our customers, and that’s how we’ve grown the business.

    Shimel: Sure. So, and Jonathan, you know, kidding aside about overnight sensation, that’s the right way to build the business, right? You don’t just—I mean, yeah, everybody wants to be a unicorn, but unicorns are mythical, right? [Laughter]

    Fries: [Laughter]

    Shimel: [Cross talk] the world and all of that, so good for you guys. But you know what I didn’t mention is, what exactly—and just sharing with the audience, what’s your position with Exadel?

    Fries: My title is Vice President of Engineering and Digital Transformation. So, my background is in the software development world doing software development, leading teams, eventually sort of managing engagements and things like that, and also today heading up the digital transformation practice inside of Exadel.

    So, my background comes from the technology world and software development, and that’s why I’m proud of—I’m proud of our engineering capabilities and what we’re able to do for customers.

    Shimel: Good for you, good for you. So, Jonathan, you know, digital transformation is such a buzzword today, right?

    Fries: Yep.

    Shimel: We’ve all heard it, you know, and the one thing I’ve learned is that, for many organizations, you know, digital transformation is hard, right? I’ve heard so many people say, “Well, this wasn’t as easy as it was made out to be.” And I think one of the issues is, is that, if you can’t define something, how can you achieve something? Right?

    Fries: Yeah.

    Shimel: And so, it starts with, “Well, what exactly does digital transformation mean?” And so, I’ll throw it back at you—what does digital transformation mean to you?

    Fries: So, digital transformation for us is about helping our clients with the—you know, the doing and the engineering work of doing digital transformation. So, it’s about software development—you know, in particular it’s cloud development today—QA automation, and DevOps. I mean, those are really the big three areas of expertise within the company that we’ve really brought together under the digital transformation sort of heading as well as our agile methodology expertise, and so, bringing kind of those four things together. And they completely make sense together, because, you know, DevOps is really kind of the technology reflection of agile methodology and agile methodology is kind of the methodology reflection of the DevOps technology mindset. And QA automation is so tightly wound into DevOps and really the way that we’re delivering software and the way that our DevOps solutions work are very much married a lot today to cloud development.

    And so, we’re bringing all of those things together, which are all things that Exadel had lots of expertise in, but figuring out how to make sure that we were weaving those strands together, if you will, in a really sort of explicit way and building up some solutions for clients. Not just, “Hey, we’re really good at those things, and we have people who can be really good at those things for you,” but we can bring all of our best practices together and some technology solutions together.

    So, that’s what it is for us. It’s very much, you know, we’re a software development, software engineering firm, so we really—you know, we’re not sort of going after the cultural transformation part of that, or the, you know, the change management. I mean, we certainly have experience with those things, but for us, it’s really about the development side of it and our expertise in helping clients take on hard projects and succeed.

    Shimel: Absolutely, absolutely. Let’s talk a little bit about something new that Exadel recently delivered, and that’s the Innovation Lab. Talk to us—what exactly is the Innovation Lab?

    Fries: Yeah, the Innovation Lab is, it’s a new offering that we’re bringing to the market that combines some things that we already have into one thing. So, you know, we’ve all heard about the importance of innovation and even innovation labs. You know, some companies have them or are creating them. Exadel’s Innovation Lab is sort of more of a virtual innovation lab as opposed to, say, a physical place that we help someone create.

    So, we already have something called Appery, which is a cross-platform, low code development environment for creating cross-platform mobile apps as well as, like, a low code backend that runs behind that. So, that’s a way to build software very quickly to create real, working software.

    We already have a lot of expertise in agile development, as I mentioned before. And so, that’s also part of what we do. We have really great resources, all of those developers that we have, you know, in Europe and some here. And we have some packaged solutions that are a part of those practices.

    So, we’re bringing those all together to help our clients innovate. So, you know, what we wanna do is help our clients who are looking for a way to move faster, experiment, try something, get some features in front of customers or business stakeholders more quickly, and the Innovation Lab is our sort of packaged solution for doing that.

    So we can, we bring all of those things together—low code development, agile, on-demand resources when there might be something. Since a lot of what people what to experiment today are things like artificial intelligence and blockchain and how can we make those things work for us, so that’s—you know, often, we might have to bring in, you know, we might have to bring in an expert to help out with that as well.

    So, it’s really, it’s all of those things to help our customers and new customers innovate more quickly.

    Shimel: Got it. So, you know, and to me, when I look at it, Jonathan, you know, we talk about digital transformation, and what I said before about how, if you can’t define it, how can you be successful, and even once you define it, it’s an experiment in a lot of ways, right? It’s kinda that classic DevOps where you deliver, you learn, you get feedback loops, you iterate, you reiterate, and you keep reiterating.

    And an innovation lab is kinda the perfect place to kinda have that sort of learning that propels, that helps you define and then succeed in your digital transformation, right?

    Fries: Yep.

    Shimel: You know, you don’t wanna practice, I guess, on live TV or stuff like that. But you need—you need these labs to push the envelope and find out what works for you and what doesn’t work for you.

    Fries: Yeah. I very much view it, you know, as an extension of the product owner, you know, life cycle from scrum. You know, there’s the regular sort of software development life cycle within scrum where you’re doing your sprints and you’re delivering software.

    Shimel: Mm-hmm.

    Fries: But a big part of what the product owner should be doing is developing the product backlog which includes, you know, testable hypotheses. That’s kinda the way that the scrum community talks about it.

    And so, the Innovation Lab is a way for product owners to test some hypotheses that they might not be able to test, you know, if they already have a product. Like, you may not wanna do all the work to develop it and test the hypotheses over here, or that hypothesis over here. You may wanna use something like the Innovation Lab where we can use some of the tools at our disposal to create something that you can deliver and test out one of those—you know, test a hypothesis kind of on its own, if you will—but with working software. Which, you know, as we know is also a big part of agile and DevOps. You know, wireframes and requirements are great and they have a place, but they’re not the best way to show people what you’re doing or get feedback, and this really allows us to help clients do that and do it more quickly.

    Shimel: Got it. I agree 100 percent. Interesting—great idea. Moving off Innovation Lab, there’s other stuff going on at Exadel. You wanna share with our audience a little bit?

    Fries: Sure, yeah. We just launched the practice areas. As I mentioned, I’m the head of the Digital Transformation practice, and we also have a Digital Marketing Technology practice and a Products and Platforms practice that, much like digital transformation, the other two are also things that, you know, in places where we already have a fair amount of expertise and were kind of collecting all of that together in one place.

    So, for Digital Marketing Technology, we have some pretty significant clients for whom we’ve done work with Adobe Experience Manager to build global, localized, large scale websites. And since we had really done that several times, the Digital Marketing Technology practice is all about packaging that solution and delivering that to other clients for kind of building those large scale worldwide type of websites with Adobe.

    Products and Platforms is—you know, given that we’ve developed Appery, which really is, you know, it’s not just an application, it’s a whole platform for building other applications, and we’ve done that both for ourselves with Appery as well with several of our other clients like GHX where we’re creating a lot more than just an application, it’s this whole ecosystem. And so, that Products and Platforms practice sort of brings together the best of our knowledge base about developing those really sophisticated, large scale platforms.

    And Digital Transformation, of course, which is mine, is all about DevOps, cloud tech, QA automation, and agile. We have a solution that we’re putting together within the Digital Transformation practice that is a cross-cloud Kubernetes implementation that’s all done with Terraform and we’re actually getting ready to use that with the first customer now. We’ve kinda been just doing our internal dev on it, but we’ve shown it to some people and they’re pretty interested in that. The first customer will probably just use it on Azure, but it’s got some really sophisticated—you know, deploying Kubernetes with Terraform, autoscaling, a lot of really cool tech for containerized application development. So, I’m pretty excited about that.

    Shimel: So am I. I mean, it’s an exciting time to be alive in IT. I mean, from a developer point of view, from an ops point of view, there are so many options and so—you know, such power at your fingertips.

    Fries: Yeah.

    Shimel: It really is, you know, it’s a golden age to be into this kinda stuff.

    Fries: Yeah, I agree. I mean, I just—I think it’s an amazing time and, you know, I think there’s so much opportunity. There’s so much opportunity out there in what you can do and so forth and then how easy it is now to, you know, to bring computing solutions online for stuff, you know, and it’s what can be done.

    It’s awesome, and I know that, you know, it’s a lot of change and it can be hard on people sometimes, but I’m definitely an optimist and an “all ships will rise” type of guy, so, you know, I see all those opportunities out there and it’s like—you know, yeah, there’s an awful lot exciting going on.

    Shimel: Well, you know, Jonathan, I think in our business, either we can be optimists, or we can be cynics.

    Fries: Yeah.

    Shimel: I got into it yesterday, some guy, I don’t even remember his name, but he tweeted, “Oh, those DevOps people selling snake oil! There’s no such thing!” I think they reach a certain age where they just feel like there’s nothing new under the sun, and therefore, they’re just gonna bad mouth, right, whatever new comes along, and—hey man, you know, there’s a place for them on Earth, too, I guess.

    Fries: Yeah, and I mean, I think there’s always, I think, a real reason to be concerned about automation and the changes that that brings to not just our industry, but all of society. I mean, you can look around and see how much automation is impacting everything and, you know, as somebody with—you know, I have kids who are grade school aged kids, and it’s like, the world’s gonna look a lot different 20 years from now, so here’s what you need to spend your time thinking about and learning. Because, you know, if you really wanna do this kinda job, it’s not gonna be there 20 years from now.

    Shimel: And I have kids in high school and college and I’m telling them the same thing, man. It’s a crazy world. But you know something? To me, you know, we talk about being optimist, pessimist—Jonathan, the flip side of digital transformation is disruption.

    Fries: Yeah.

    Shimel: Right? And so, you get to the haves and the have nots. You have the empowered people who embrace transformation and are accelerating their business, and you have the laggards who don’t, and they may very well have to die off, right?

    Fries: Yeah.

    Shimel: I think that’s the choice that we—you know, that it’s nice to talk about this golden age, but that’s also the choice out there is, you can get with it or fall by the wayside. It’s compete or die. And, you know, that may be harsh to some, but that, I think, is the way it is.

    Fries: Yeah. It’s kind of been true for, you know, for a while, honestly. Industrialization automated some things, and like I said, I think, at the end of the day, the new businesses that will be created by digital transformation, the businesses that will be completely transformed by digital transformation will create, you know, even more opportunity, and as long as you are looking at it through the lens of those things, even though automation can be—you know, it can be scary.

    I mean, like I said, I came from—I was a developer and worked in IT and things like that, and you know, there was lots of things even 20 years ago, where it’s like, “Oh, these things are gonna change everything and jobs will go away” and it’s like—you know, that’s—

    Shimel: [Cross talk] Doesn’t happen, doesn’t happen. Anyway, Jonathan—

    Fries: No, it happens.

    Shimel: – when we started, I told you, the 15 minutes goes really quick, man. [Laughter]

    Fries: Yeah.

    Shimel: And we’re way over already. I apologize, but I didn’t wanna stop you, you were on a roll, and I thought it was a good conversation. So, but we’re gonna need to pull the plug on this episode of DevOps Chat. Jonathan Fries from Exadel, thanks for being our guest today.

    Fries: Absolutely, Alan. It was great. Thanks for having me.

    Shimel: Alright! This is Alan Shimel, DevOps.com, and you just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Institute Brandjacking: When Imitation is Not the Sincerest Form of Flattery

    DevOps Institute Brandjacking: When Imitation is Not the Sincerest Form of Flattery

    “There can be only one”    ~ Duncan McCloud, Highlander

    They say that imitation is the sincerest form of flattery. Often it is absolutely true. But stealing, ripping off and/or trying to trade on the name of others crosses the line between right and wrong, legal and illegal. As a co-founder of the true, one and only DevOps Institute, I was appalled to see the efforts of another company, whose name I won’t even dignify in this article, trying to launch “the DevOps Institute.”

    If you told me that this company perhaps did not know that there was already a DevOps Institute (it’s not like we hide it), I would say OK, maybe it was an honest mistake. But no. In this case, the company in question actually reached out to DevOps Institute—us—and had several conversations/interactions regarding becoming a registered education partner of the DOI. What the company reps were actually doing was fishing for information as they sought to launch their own version of DevOps Institute. So this is certainly not a case of an innocent mistake; rather, it’s a deliberate attempt to misappropriate the name, assets and hard work of another. Where I come from, the streets of NYC, we call it stealing.

    You have to ask yourself: Knowing what we know of the situation, why would these people commit such an unethical, illegal act? I can only come up with a few reasons:

    1. They are seeking to deceive and confuse the public by literally trading on DevOps Institute’s—our—good name to make a quick buck.
    2. They are part of those in the world who do not respect intellectual property, seeking to sell out the back door anything they get their hands on from the front door.
    3. They are unscrupulous thieves who are incapable of building a business by themselves.

    No matter whether one or all of the above, none of the reasons are very good.

    In generally acceptable business practices worldwide, there are more than several acceptable ways for companies to imitate the business strategy and models of others. More power to them—after all, competition makes us all up our game.

    In the DevOps education training and education space, there is certainly no shortage of competitors. Just do a Google search of DevOps Institute and look at the companies buying that ad word or otherwise using SEO to get listed. Lots of competitors, for sure. Remember, this isn’t even a generic “DevOps training” search, but actually searching for DevOps Institute.

    Taking another’s name crosses the acceptable boundary. So now we have to lawyer up to protect our rights and property. No one likes to throw good money at lawyers to go after bad actors. But protecting one’s brand, reputation and IP is that important.

    For those of you familiar with the DevOps Institute, you know that the team has worked hard for more than four years now to lead the way in curating content for bringing DevOps training, education and certification to the market. It hasn’t always been smooth sailing. When DevOps Institute launched, we faced strong headwinds from those who thought a training/certification program around DevOps was wrong. We listened, we learned, we set up the feedback loops and we iterated (like good DevOps should). We have won over many of our critics; they saw the good work we were doing.

    More than that, they saw DevOps Institute try to be stewards of and active participants in the DevOps community. We are not in this for the fast buck or the quick hustle. The executive team has plowed our revenue back into the company and community, expanding the association’s offerings and reaching out to DevOps communities throughout the world. Today, DevOps Institute has ambassadors in Europe, South America, AsiaPac and of course here in North America. We go wherever DevOps goes.

    Recently DevOps Institute has tried to build a greater DevOps community based on the Humans of DevOps and our SKILS framework (Skills, Knowledge Ideas and Learning). We have worked with the leading names in the DevOps industry to do research and help bring greater understanding of DevOps. We have sponsored and spoken at many of the DevOps events you have attended. In fact, I am satisfied to rest on our laurels.

    If you are not familiar with the real DevOps Institute (and that is at https://devopsinstitute.com, btw) check it out for yourself. We have nearly 200 partners around the world who deliver training for our certifications. We have a healthy global community and active engagement with industry thought leaders. We obviously are doing something right.

    Finally, I wanted to speak to my entrepreneur friends in the audience: Those of you know who know me, know that this isn’t my first rodeo. I have founded and helped several venture-backed startups through IPO and exit. I have had my share of wins and my share of losses. I am not one to whine or back down from some good competition, but this kind of shadiness has no place in the business world.

    We put a good chunk of our own blood, sweat and tears into our businesses, and for someone to swoop in and steal the fruits of our labor is just plain wrong. Brandjacking is stealing. I started this article off with the quote from “Highlander.” So if you see me walking around with a severed head or sword in my hand, remember: There can be only one.

    — Alan Shimel

  • Insight IGNITE: DevOps, Cloud and Cyber From Iceland With Love

    Insight IGNITE: DevOps, Cloud and Cyber From Iceland With Love

    I had the pleasure recently of attending my first Insight IGNITE event, which was held at the ION Adventure Hotel in enchanting Iceland. It was also my first trip to Iceland. These two new experiences combined to deliver an excellent learning and networking experience, resulting in me realizing more than several new insights (pun intended) around DevOps, cloud and cybersecurity, as well as mindfulness and contentment.

    The agenda for this particular IGNITE event featured some great examples and discussion around DevOps, cloud migration and infrastructure and cybersecurity, among several others. All three of these were right in my wheelhouse, so I really enjoyed the presentations and discussions. I couldn’t type fast enough to keep up with all of the insights I was soaking in. Of course, I was also trying to contribute to the conversations, which are held in a very open, communal manner under Chatham House Rules.

    You may not be familiar with the Insight IGNITE Innovation Roundtable Series. They are the brainchild of Insight Partners’ Emmet B. Keeffe III. Emmet is beyond passionate about digital transformation (among several other passions including Formula One racing, world peace and now mindfulness/contentment). Utilizing his vast network (and it is vast), Emmet founded Insight IGNITE, an innovation program that delivers Innovation Briefings, the Innovation Roundtable Series and Growth Advisory Board opportunities to global IT leaders. I know that sounds like marketing speak, but let me explain.

    Basically, Emmet holds about one of these events a month at some of the most fascinating venues on earth. Each one has ~50 people. There is a mix of C-level executives from some of the 200+ Insight Partners portfolio companies, along with executives past and present from large global enterprises, sprinkled in with a mixture of technology experts and subject matter experts (I guess that is what got my ticket punched). The agenda is an exhilarating mixture of roundtable discussions and presentations on subjects touching on Digital Transformation, along with exciting activities that allow attendees to experience the local venue.

    The events are open to Global 2000 executives and other business and technology experts who think they could both benefit from this type of experience as well as have something to offer.  You can reach out to Emmet’s team if you are interested in attending one of these events.  Most attendees have to cover their own airfare/hotel. While not cheap, it is well worth the money, and the IGNITE team, who are extraordinary, do an amazing job of keeping it fresh, fun and challenging.

    The real special sauce of the IGNITE Roundtable Series, though, is the passion, caring and love that they receive from Emmet’s team. It is infectious and spreads to the attendees as well. I have attended hundreds of conferences over the years and don’t remember one where I made as many connections, had as many great side conversations and really felt part of a group. I am sure many of the people I met at this event I will be in touch with and doing business with in the months and years ahead.

    I met Emmet about three or four years ago in London (where he lives with his family now) and was invited to a previous event or two but was unable to make it. Since then, it seems Insight Partners is investing in so many of the companies that we work with here at MediaOps in DevOps, containers and cybersecurity—including Tricentis, JFrog, Aqua Security, Firemon and others. If you can’t beat ’em join ’em, as they say, so I decided to take Emmet up on his kind invite and check it out.

    The IGNITE event in Iceland had several great presentations about disrupting your own company product by spinning up the disruptor internally. We heard from “a queen of transformation” who has led transformations at several large multinational and government agencies. Another presentation focused on how an energy company keeps transforming as it stays ahead in today’s ever-shifting market and sets the bar for what the energy company of tomorrow looks like. In addition, there were some great panel discussions on the current state of DevOps and Agile, another on the state of cloud migrations, hybrid cloud and next-generation infrastructure. Also on the agenda was a great discussion regarding what is happening in cybersecurity and how critical it has become as part of any transformation. All of these were great, but what made them better was the great discussions they sparked among the attendees.

    That was not the full roundtable agenda, though. We also had a private briefing with the first lady of Iceland, discussions on some new fintech companies and technologies, AI/ML and more.

    But perhaps some of my favorite presentation and discussions were on a new passion of Emmet’s called the Contentment Foundation. This is a breakthrough effort to bring a new take on making education better for the world of today and tomorrow. Led by Dr. Daniel Cordaro, it recognizes that children are truly our future. How can we make them more content and mindful, better equipped to handle the world of tomorrow and the challenges they will face? The Contentment Foundation has developed a curriculum that is available to just about any school in the world. If you know a school that you think could benefit from this, I encourage you to reach out to them.

    All work and no play would make for a boring event, though. My trip to Iceland at the Insight IGNITE Roundtable was far from boring. We visited the famous Perlan Planetarium (which, unfortunately, was as close as I got to seeing the Northern Lights on this trip); ate in a Viking-themed restaurant; and rode ATF vehicles through the rugged, lava rock-strewn, stream-filled Icelandic countryside. We explored a lava tube cave and more. Unfortunately, the weather didn’t cooperate, so we had to cancel snowmobiling, whale watching and dinner on an island off the Iceland coast. I stopped off before heading to the airport to explore a bit in the capital of Reykjavík, which is a great little city with great cafés, shopping and sights.

    Even the social activities provided some great bonding and networking opportunities. It is rare for me that I not only make business acquaintances, but also form friendships at events like this. To me, this was yet another unique feature of the IGNITE Roundtable: People were there genuinely to share their experiences and discuss the burning topics at hand.

    All in all, one of the best events I have attended in a long time. I highly recommend attending at least one of these IGNITE Roundtables, if this sounds like something you may be interested in. As for me, I am already looking at what is the next one I will be able to attend. Once I have had a chance to digest and percolate on some of the insights I experienced, I will share a follow-up article to share them with you.

    Thanks, Emmet and IGNITE team, for a great experience.

    — Alan Shimel

  • The DevOps Institute Has Been Brandjacked

    The DevOps Institute Has Been Brandjacked

    Sadly, another organization has decided to brandjack the DevOps Institute name. Quickstart, an e-learning organization based in Austin, Texas, recently approached DevOps Institute about becoming a channel e-learning partner. Instead of joining our partner community, Quickstart chose to stand up another “DevOps Institute.” Since they were in communication with the actual DevOps Institute as late as March 9, I can only assume that this was an intentional act to confuse the market into believing that they are somehow associated with (or are) the actual DevOps Institute.

    They are not.

    Since 2015, the DevOps Institute has spent countless hours, attended numerous conferences and invested significant resources in advancing the human elements of DevOps. We were the first stand up formal association to focus on DevOps learning and certification as DevOps was emerging in the enterprise space. We are known and respected by many of the key DevOps thought leaders and vendors. We recently fielded the “Upskilling: Enterprise DevOps Skills Report” with the support of Electric Cloud, CloudBees and Lenovo. We not only talk the talk, but we also have demonstrated time and again that we are committed to walking the walk and are heavily invested in the goals of the DevOps community.

    To be clear, we have no issue with fair competition, particularly in a space that is growing as quickly as DevOps. That’s the nature and risk of running a business. Competing on products or offerings—that’s expected, and it ultimately helps the people within the industry succeed. Hiding behind another organization’s brand, though? That’s not only unethical, it defies every value that is at the heart of DevOps and established business practices.

    I thought long and hard about whether to give Quickstart and www.devopsinstitute.io visibility by exposing their actions. The easy way would be to stay quiet and let the lawyers sort this out (which they certainly will). However,  the real DevOps Institute stands by our moral obligation to the DevOps community and we, therefore, cannot let an imposter bully us into silence. The dictionary definition of an imposter is “someone who pretends to be someone else in order to deceive others.” Quickstart is an e-learning company masquerading as a well-respected DevOps association, presumably for commercial gain. What do you think?

    Please do not be deceived by imposters that falsely attach their services to DevOps Institute in the hope of benefiting from the goodwill we have established with our brand in the DevOps community.  There is only one DEVOPS INSTITUTE (www.devopsinstitute.com) and we are wholly committed to advancing the human elements of DevOps through our SKIL (Skills, Knowledge, Ideas and Learning) framework.

    Buyer Beware!

    — Jayne Groll

  • The Right DevOps Tool for the Job

    The Right DevOps Tool for the Job

    Innovation and environment are only two factors in determining which DevOps tools are best for your organization

    Any time there is a movement in IT that involves a new space and new toolsets, there is sudden growth, then inevitably consolidation and, finally, a selection of tools that suit the needs of most customers. Then the cycle starts over. Usually by this point, users have developed a defense mechanism about their choices regarding which solutions to implement and discussions can get heated.

    I’m happy to say that the last bit—heated discussions—has not occurred with DevOps the way it has with other technologies (think the browser wars, OS dominance or even cloud service provider preferences). There is the occasional “You’re doing it wrong,” but not the wild-eyed flame-wars so far.

    But the other two? Yes, yes indeed. DevOps has been through a couple of cycles, and the end is nowhere in sight. I don’t necessarily see that as a bad thing; in fact, as long as innovation is occurring, you have the opportunity to look at changes and decide what can best help your DevOps efforts.

    My mantra since the language wars was that C, C++, VB, etc., were the “right tools for the job.” I have kept that mantra for all of IT. It is easy to adapt the tools you are familiar with—to do more than they were designed to—and most shops have fallen into this trap at some point. But a serious look at what is available and where the market seems to be evolving usually stops this kind of adaptation.

    Some shops use Jenkins for far more than it was designed for. It’s a great tool, but at some point, the benefits of using tools aimed at a given piece of the DevOps toolchain outweighs the fact that Jenkins could handle that bit.

    The popularity of Puppet is starting to cause the same issues, if anecdotal evidence is to be believed. In words I use to my children, “Just because you can, doesn’t mean you should.”

    The environment always plays a role in the “right tool for the job,” but it should not be the major factor. Having a DevOps tool that you already know that could do the job is one answer—but quite often not the best answer.

    So, use resources like us here at DevOps.com, and your favorite site for IT ratings and reviews. Do some feature research, think about what it would take to make your existing tools do the same job, and consider bringing in new tools to achieve a given goal. We see so much change these days that sticking with what you know on this one tiny bit of the toolchain, may seem reasonable, but make sure you are not missing out on additional functionality or suitability to task over the long term.

    — Don Macvittie

  • DevOps Market Consolidation Gets Real: CloudBees Acquires Electric Cloud

    DevOps Market Consolidation Gets Real: CloudBees Acquires Electric Cloud

    You may have already seen the news today: CloudBees has acquired Electric Cloud in a move that marks a true market consolidation in the DevOps space. I had a chance to speak with CloudBees CEO Sacha Labourey to discuss the acquisition. We discuss the motivation for the deal, what the combined entity may look like going forward and more. The video of our conversation is at the bottom of this article.

    In my mind, this acquisition represents true consolidation of the DevOps tool vendors market. My reasons for this are as follows:

    1. Until now, many of the acquisitions in the DevOps space have been by large, established public companies such as CA, HP or IBM. Typically, these kinds of deals are not as much consolidation as they are large companies using M&A activity in place of R&D. CloudBees is not a large vendor—this isn’t R&D dressed in an acquisition.
    2. Electric Cloud is not your typical venture-backed startup that is looking for exit opportunities. The company has been around for many years. It has a large base of enterprise customers and an enterprise-tested product.
    3. With the recent changes in the DevOps vendor market involving CA (now Broadcom), HP(E) now Micro Focus and IBM preoccupied with Red Hat, there is a vacuum for enterprise leadership. The combination of these two vendors of scale is really a consolidation move.

    Best of luck going forward and congratulations to our friends at CloudBees and Electric Cloud. It will be interesting to see what repercussions this deal brings to the rest of the DevOps market.

    For more details on the acquisition, check out Mike Vizard’s article in DevOps.com today. In the meantime, enjoy the video and conversation with Sacha. Also, let us know what you think about the acquisition—and other M&A activity in the DevOps space—in the comments section below.

    — Alan Shimel