devopsy.kinsta.cloud

Category: Blogs

  • FaaS is Key to DevOps Efficiency

    FaaS is Key to DevOps Efficiency

    When AWS announced Lambda–a serverless Function-as-a-Service (FaaS) technology offering–the idea of encapsulating a specific task into a function that resides in the cloud was introduced into mainstream access.

    Now, with the rising popularity of microservices, DevOps is waking up the benefits of FaaS where it is used to build and maintain enterprise applications in agile environments. The move to serverless architecture using FaaS is one organizations are now increasingly likely to investigate in 2019.

    Given these industry realities, we need to ask ourselves what place will FaaS take in contemporary computing environments and how will its core efficiency proposition enable DevOps to flourish and improve experiences for users at every level?

    Back to Focus

    First let’s remind ourselves what any FaaS platform really does. It allows us to focus on developing and executing business logic because server provisioning and management is handled automatically at the backend. Developers can deploy applications into a space with zero server administration, yet with the ability to enjoy high availability and high scalability.

    The impact for DevOps is immediately apparent.

    Developers are able to work in a zone where they are essentially abstracted away from the servers their applications live and breath on. The services developers draw upon are event-driven and eminently scalable. Even if they have to scale by some massively parallel level of magnitude, server-side service optimization is handled at the backend by the FaaS vendor.

    At the same time, the cost structure is shifted and operations staff are able to oversee compute billing models based on actual execution of functions, as opposed to being dependent on the physical size of a pre-provisioned cloud server established at best guess size and core optimization parameters for compute, I/O, storage, analytics and so on.

    Speedier Implementation

    If we have so far looked at the FaaS efficiencies that reside at the backend server-side management element of the equation, let us also turn our attention toward the way FaaS allows developers to reduce the amount of time it takes to deploy code in a new environment.

    Adopting a FaaS-centric approach to application architectures allows the developer team to encapsulate specific software tasks into functions, hence the name. For a mortgage calculation application, for example, we can encapsulate functions such as interest rate calculations, payments, length of contract etc., and then place those functions in the cloud on a FaaS platform. The FaaS provider is responsible for the hosting of that function and also looks after the heavy lifting associated with availability and redundancy.

    The benefit to developers is a very rapid environment for deploying new code, getting feedback and iterating. The operations benefit is one of hosted happiness as the FaaS provider shoulders a significant administrative burden.

    FaaS and microservices are now increasingly viable options in any modern technology architecture and it’s important to distinguish between the two.

    Microservices are made up of self-contained elements of business logic designed to perform a very specific job. They are optimized for their single responsibility and can communicate with other services via application programming interfaces (APIs). Further, they can be developed, deployed and scaled independently without impacting other services.

    A FaaS-based approach is well-suited for transactional workloads where code is run periodically. This is also a technology that is quicker to establish, as and when needed. A FaaS function might also make a call to other application logic that (in the case of our mortgage example) calculates interest rate and so on.

    FaaS Challenges

    Like any still-nascent technology, FaaS has its functionality flaws and challenges. The automated nature of foundational provisioning in FaaS is great news, but it’s not a panacea.

    Why? For one, DevOps teams will have limits on the debugging capabilities for applications that run on FaaS DNA. Also, functions are instantiated and then de-instantiated as needed, which requires time, especially for a cold start. This process can cause unwanted delays in time-sensitive operations. The transient nature of FaaS also impedes state preservation among dependent functions, which requires careful design considerations.

    FaaS is a place where the burden of server resources control has been shifted. But there’s no such thing as a free lunch and this means DevOps won’t be able to interject some level of application monitoring function at the server level itself. You’ll need to know more about your FaaS-based application before you FaaS it up.

    We must also remember for any distributed software architecture, there’s an up-front responsibility to design to accommodate the limitations and increasing options available in modern services.

    The FaaS Road Ahead

    Examples of FaaS now extend beyond AWS Lambda, we can also look to Microsoft for Azure Functions, Google for Cloud Functions, IBM OpenWhisk, Oracle Functions, Fn Project and IronFunctions with its Iron.io platform.

    This sector of the software landscape is guaranteed to grow over the coming years. FaaS can be an appropriate option in an overall software architecture, but there are specific limitations, so choose wisely. Observing the evolution of FaaS over the coming years will be a fascinating process.

    — Mike Duensing

  • Aim to Be a Top 12% Global Testing Team

    Aim to Be a Top 12% Global Testing Team

    We know that you’re thinking, “Really? Another fluff post about the top people in my profession and what I need to do to be just like them?” Listen, we hear you, but this is not some fluff piece with vague ideas of what might (or might not) work.

    In case you missed it, on May 27th, the 2019 State of Automated Visual Testing was released. Based on independent research sourced from over 350 testing teams around the world, we learned 12% of you are getting much better results than the other 88%. We’re talking four times more successful as measured by the things you (and your boss) really care about–test coverage, release velocity, application quality, overall R&D teamwork and cold hard cash. This is not our opinion. It’s not subjective. It’s objective data and information. Data and information that came from you and your peers.

    In other words, we’re not asking you to take our word for it; we’re asking you to take your word for it.

    What Separates the Top 12% from the Other 88%?

    Digital Transformation. Two words that have been baked into our world over the past 20 years. To such an extent it may be fair to call it fluff? Fluff or not, IDC forecasts worldwide spending on technologies and services that enable digital transformation will reach $1.97 trillion in 2022, per the (IDC) Worldwide Semiannual Digital Transformation Spending Guide.

    That’s a lot of fluff! When your bosses’ boss is spending that kind of cash, it’s always worth paying attention. It could be good for your career. As it turns out, 12% of the world’s testing teams did pay attention, and it’s their approach to managing the challenges of digital transformation that have set them apart.

    The Testing World’s Digital Divide – Digital Transformation Quantified.

    You can quantify it for yourself with some simple math and see how you compare to other R&D and testing teams around the world. Got that calculator ready? Here we go…

    How many applications do you have in production today? (Don’t forget those native mobile apps, they really add up).

    How many pages or screens do you have in production on average for each of these applications? (Single page applications can be tricky but give it your best guess).

    How many viewport breaks do you support? (The market average is six if you are not sure).

    How many human languages do you support? (We’re talking about localization here–English, German, Spanish, Chinese, Japanese–not coding languages in case you’re wondering).

    Now, multiply those four numbers together. Congrats! You have just quantified the digital footprint of your business. People can write about digital transformation all they want, but you’ve just transformed all that fluff into something quite real. It’s probably a big number. Over 90,000 for a typical company and over 624,000 for the largest 30% of companies in the world. Here’s the kicker. You and your R&D team are responsible for managing the visual and functional quality of every single one of those pages and screens.

    When functional test automation first emerged way back in 1989 with the launch of Mercury Interactive XRunner, it was a much different time. Browsers didn’t even exist. Since then, the browser wars have come and gone, and standards are now in place. Applications have grown far more complex with native mobile, dynamic content, single page applications (SPA) and responsive design now an everyday reality. Digital transformation for any size company is officially past tense. We’re not transforming, we’re transformed. And now you have to deal with it, but how?

    What Defines a Top 12% Global Testing Team?

    Top 12% teams have overcome the massive challenge posed by digital transformation. Like any technical challenge we have ever faced, it started with someone on the team who felt the pain and set out to solve for it. And when they did, good things happened:

    • Test coverage increased by 60%
    • Release velocity became 2.8x faster (even though coverage increased 60%)
    • Visual and functional quality improved 3x with far fewer escape bugs (even though they release 2.8x times faster)
    • R&D teams are 4x more satisfied with their visual and functional quality outcome

    All of this despite the 12% of testing teams were managing applications 2.2x larger than the other 88%. In all likelihood, they felt the pain before most of us, and have now led the way for the rest of us. We just need to follow.

    Today, successful continuous management of application visual quality creates competitive advantage. Business leaders know this and are paying attention. As a result, testers are in a better position than ever to be heroes respected by their R&D teams for driving huge value for the companies they work for.

    — James Lamberti

  • Mendix Injects More AI to Accelerate Low-Code Development

    Mendix Injects More AI to Accelerate Low-Code Development

    The rate at which low-code applications are built and deployed will accelerate as developers begin to rely more on artificial intelligence (AI) to write code. The summer 2019 release of the Mendix low-code platform includes a revamped instance of Mendix Assist, which employs machine learning algorithms to make coding recommendations. Those algorithms have been trained using data drawn from 5 million application models employed across 15 industries over the last 10 years, and Mendix claims this version of Mendix Assist improves the accuracy rate of the recommendations being made to 95%.

    Sheryl Koenigsberg, director of product and solutions marketing for Mendix, said Mendix Assist will enable new developers to write better code faster, while experienced developers will be able to employ Mendix Assist to address routine issues that often get overlooked faster. Mendix Assist not only advises developers on what to do next but also generates recommended actions in previous logical steps based on whatever new code is introduced in the application.

    Mendix

    To make these capabilities more accessible, the summer release of Mendix adds Mendix Studio and Studio Pro, a set of integrated development environments designed to be accessible to both citizen and professional developers, to the low-code platform.

    In addition, Mendix is adding support for native mobile application development by adding support for React, a set of JavaScript libraries for building user interfaces for mobile applications, and including a native JavaScript editor. Those capabilities eliminate the need to rely on emulation software when building mobile computing applications, said Koenigsberg. Because the Mendix IDEs integrate low-code abstraction across iOS, Android, Java and Objective-C programming models, it also becomes easier for mobile developers to build reusable components. Mendix has also included more than 50 pre-built connectors to mobile device capabilities, such as camera, geolocation, biometric authentication and Bluetooth enablement, along with support for conversational chatbots and voice interfaces such as Alexa and Siri.

    Longer-term, Koenigsberg observed that it’s conceivable the AI capabilities being included in application development tools eventually will share insights with AI models being incorporated into continuous integration/continuous deployment (CI/CD) platforms. Proposed changes to an application could, for example, might be assessed from a performance perspective before any lines of code are written.

    In the meantime, the rate at which low-code applications will be moving through CI/CD platforms is about to increase substantially as developers augment their own skills by relying more on recommendations surfaced by AI engines. The quality of those applications should also improve as AI engines check, for example, to make sure all the appropriate compliance and cybersecurity controls are in place.

    It’s not likely AI engines will replace the need for developers anytime soon. However, it is apparent all the little things that routinely conspire to slow application development and delivery processes increasingly will be automated. That should make it easier for a larger number of organizations to embrace best DevOps processes. After all, the primary issue with DevOps adoption these days is not necessarily appreciating the value of the concept, but rather managing pipelines that still tend to get clogged every time an application fails to pass a gate because a developer forgot to do one thing or another.

    — Mike Vizard

  • Why Did DevOps Become So Popular? 3 Theories

    Why Did DevOps Become So Popular? 3 Theories

    DevOps has now been a thing for a solid decade. As we look back at the history of DevOps, it’s worth asking: Where did DevOps come from, and why did it take off when it did?

    In honor of the 10-year anniversary of DevOps, I’d like to explore these questions.

    A Brief History of DevOps

    The very basic history of DevOps goes like this: First, there was agile, an idea exemplified in the Agile Manifesto that gained prominence among software developers in the early 2000s.

    Then, in 2008, Patrick Debois, a developer from Belgium, conceived of DevOps as a way to improve upon the agile concept by encouraging developers to work more closely with ITOps teams. His ideas began spreading in 2009. By the early 2010s, they had gained a sizable following and the rest is history.

    That, again, is a really basic history of DevOps. For more detail, I recommend this DevOps history post by Steve Mezak.

    Why DevOps? Why Now?

    The narrative of how DevOps originated is one thing. Explaining why DevOps became so popular in a relatively short span of time is another.

    As I see it, there are three possible theories to explain the rise of DevOps over the past decade. The first is to argue that Debois simply happened to have some very good ideas, and he promoted them well. You could think of this as the great man theory of DevOps’ origins. This seems to me, however, to be an unlikely explanation. It’s very rare for highly influential ideas to be born from just a single mind, or to spread through the singular efforts of one person.

    The second possible explanation for why DevOps became popular is it is simply an evolved form of agile. This is like arguing that World War II was simply a continuation of sorts of World War I, and therefore the origins of World War II are ultimately the same as those of World War I. From this viewpoint, the history of DevOps is really the history of agile, and so DevOps itself doesn’t have a unique history at all. I’d find this argument compelling if I believed DevOps is really just agile by another name, but I don’t. DevOps is broader, and has a much stronger implementational and practical element.

    The third theory—and the one I find most persuasive—is DevOps was born out of a particular moment in the history of computing and IT. That moment, which started in the mid-2000s, was marked by several key features that helped give rise to DevOps, including:

    • The widespread adoption, starting circa 2007, of cloud computing.
    • The success of the open source software movement around 2010 in making open source the go-to licensing strategy for many popular software projects and in making collaboration around code easier.
    • The rise beginning around 2010 of microservices and containers, which made applications much more complex to design, deploy and manage.
    • The explosive popularity of mobile computing starting with the launch of the iPhone in 2007. The mobile revolution meant organizations increasingly had to deliver software for multiple target environments (PCs, Android phones and iOS, for example) at the same time, necessitating branched delivery pipelines.
    • The demand for ever-increasing speed in software delivery as a way to gain an edge in software markets which, by the late 2000s, had grown more competitive than ever.

    When you put these changes together, you end up with a need to manage much more complex, fast-moving software delivery pipelines. Powered by cloud infrastructure and microservices architectures, the software market starting around 2010 required more responsive, better coordinated management by IT teams. DevOps provided an answer by increasing efficiency, decreasing response times and making software delivery faster.

    I don’t think DevOps would have taken off if the idea had emerged in the 1990s, when there was much less demand for fast software delivery, most applications ran locally and codebases were relatively simple.

    Nor am I sure DevOps would prove as popular if it were first introduced today. At present, we have a litany of management tools (such as Ansible and Kubernetes, to name a couple of examples) that didn’t exist 10 years ago. Those tools make it easier to handle all of the complexity of modern software environments even if you don’t have a management strategy rooted in DevOps culture.

    To put it simply, DevOps resulted from the combination of several specific developments in the world of IT between the mid- and late-2000s. Debois may certainly deserve credit for helping to spread the idea, but it would not have spread so quickly if it had not emerged at that particular time.

    — Chris Tozzi

  • Blockchains Done Right Are the Next Evolution in Open Source

    Blockchains Done Right Are the Next Evolution in Open Source

    Open source code is more than just a way to create new technology. It’s a disruptive force that changed the way software is built, from taking individual developers and turning them into thriving communities to changing how enterprises do business–building open ecosystems versus restricted walled-gardens.

    The next evolution of this movement is blockchain technology. Decentralized groups of developers across the globe are contributing to greater data integrity for businesses, better guarantees to ecosystem partners and can work together on live instances including their data. And that was the missing piece–live instances. Up until now, we could only collaborate on writing the code for a system together. Today, with blockchain technology, we can also collaborate on running this system together.

    Open Source is Decentralized

    From its ideological beginnings in the 1980s, open source code changed how we do business around the world, all stemming from developers’ work in software creation. Developers have seen open source disrupting almost every field of infrastructure, from operating systems (Linux in the cloud) to databases (MySQL, MongoDB, Redis) to programming languages (JavaScript, Python, Java, C, PHP).

    Over time, open source connected thousands of developers and established a corporate precedent. In parallel, the largest corporations in the world are also the biggest contributors to open source. It is with these two transformations open source is now over 50% of all code relied upon in the average proprietary system in enterprise.

    Now, blockchain is disrupting existing business models by extending the implementations and possibilities of open software. It does so by providing a transparent and immutable record keeping method, auditability of algorithms, forking of live instances with the data and possibility facilitate governance participation, all derived from an open source, decentralized community.

    Amazon recently added support for open source blockchain frameworks such as Hyperledger and Ethereum on AWS. This is a great first step toward making this technology widely available. As more AWS blockchain customers build on the open source frameworks to build for enterprise business, the powerful capabilities of open source will become a part of the blockchain movement. Transparency, auditability and forkability in code, all present enormous opportunities for developers while also demonstrating a precedent.

    It should be noted where these instances run, whether on private permissioned networks or public permissionless ones, is material to their ability to provide external guarantees to their users. The highest standard of trust is permissionless–where any member of the public can participate in their operation and audit.

    Decentralization Rewards Both Developers and Enterprise Business

    Businesses have gained major advantages through the use of open source software. In the same way, decentralized blockchain infrastructure offers businesses increased security, robustness and most importantly, guaranteed transparency with its customers.

    Prior to the open source software movement, traditional methods of programming were expensive, slow to develop and lacked insight into user experience until long after each new release came to market. Today, developer communities download, interact and actively contribute to blockchain projects in the same way as open source. Decentralized developers give businesses rapid ability to replace arbitrary features with intentional decision-making by a large, merit-based community. Decentralized blockchains are Open Source 2.0.

    Today, most standard apps run with centralized back ends. The server hosts the back end and dictates how the database evolves, given users’ requests and transactions. End users interact through the front end and never see what’s going on behind their static experience. What if we gave users a way to shift the power structure inherent in this state? Apps could become better for their users and much more competitive.

    Not All Blockchains Fit the Open Source Credo

    There’s a wide spectrum in the industry with blockchain technologies ranging from fully public to completely private. There’s a lively debate whether the value given by these fundamentally different solutions is comparable. I argue that distributed ledger technologies or private blockchains have little technological innovation. Their validators are permissioned, which means they cannot provide unbiased external guarantees to their partners and users.

    That said, there are some benefits to using private blockchains in certain use-cases such as coordination between a small number of competitors or WalMart onboarding all its external supply-chain services onto one coordinated platform, but they are limited in giving any guarantees to anyone not participating in the consensus (i.e. not running a node).

    Public blockchains offer a business greater transparency, because there are neutral and external parties operating the blockchain outside of the company and its customers with an independent incentive system. This removes anyone’s opportunity inside the company to falsify records, as they could potentially do on a private blockchain, or have data integrity relying on business relationships and dependency. Public blockchains also live up to the ultimate test of trust–from the comfort of your home you can verify by yourself every guarantee provided by the network.

    Where Hybrid Blockchain Comes In

    Most public blockchains were designed for absolute decentralization, which makes them impractical for mainstream businesses. Private blockchains are highly practical but don’t offer the transparency and trust possible with public blockchains.

    Hybrid blockchains, such as the one developed by Orbs, offer the best of both worlds. They’re perfectly designed to address fundamental issues with performance and interoperability while allowing for applications in highly distributed environments. They provide strong guarantees, verifiable by anyone, yet leave businesses in control of their business models, governance and security.

    — Tal Kol

  • Low-Code Has Taken Development by Storm. Why Not the Web?

    Low-Code Has Taken Development by Storm. Why Not the Web?

    For more than a decade, development tools increasingly have made their way into the hands of less-technical people. On the web in particular, we’ve eliminated the webmaster as the middleman with content management systems and moved progressively toward a model where non-technical users could assemble their own sites with little to no coding experience of their own.

    Fast forward and today, the terms “no-code” and “low-code” are used to describe this idea. Furthermore, no-code and low-code tools have been on a decade-long rise, with an increasing impact on the web. Examples include:

    While this has been a strong, decade-long market trend, we’re only at the beginning. This trend won’t stop until new website experiences are automatically generated and optimized by machine learning.

    Trends Driving the Low-Code and No-Code Movements

    According to Wave, “In our survey of global developers, 23% reported using low-code platforms in 2018, and another 22% planned to do so within a year.”

    Major market forces driving this trend include a talent shortage among developers, with an estimated 1 million computer programming jobs expected to remain unfilled by 2020 in the U.S. alone. What’s more, the developers who are employed are often overloaded with work and struggle with how to prioritize it all. Some of this burden could be removed by low-code and no-code tools, allowing marketers and other non-technical professionals to do some of the development work themselves. In addition, the fact that technology has permeated every aspect of our lives, from our smartphones to our smart homes, has driven the need for more people to become creators.

    “As creating things on the internet becomes more accessible, more people will become makers. It’s no longer limited to the <1% of engineers that can code, resulting in an explosion of ideas from all kinds of people,” said Ryan Hoover, founder of Product Hunt, in a blog post.

    In other words, the supply of web creators must keep up with the demand for more digital experiences across more channels.

    But this does not only apply to individuals. Consider this: The typical large organization has to build and maintain hundreds of sites. These organizations need to build, launch and customize sites in days or weeks, not months. Today and in the future, marketers and other non-technical stakeholders can embrace no-code and low-code tools to develop websites rapidly.

    Abstraction Drives Innovation

    As predicted in my middleman blog post, developers won’t go away. Just as the role of the original webmaster has evolved with the advent of the CMS, the role of web developers is changing with the rise of low-code and no-code tools.

    Today, developers tend to focus on creating next-generation digital experiences that require new and emerging technologies not yet available in no-code solutions. In the process, they help invent and build new technologies such as React, Vue.js, etc.

    Successful no-code approaches abstract away complexity for web development. This enables less-technical people to do things that previously only could be done by developers. When those abstractions happen, developers can move on to the next area of innovation.

    Such abstractions are a good thing for both developers and non-technical website creators. When everyone is a builder, more good things will happen on the web. I was excited about this trend more than 12 years ago and remain excited today. I’m eager to see the progress no-code and low-code solutions will bring to the digital world in the next decade.

    — Dries Buytaret

  • Machine Learning and Predictive Analytics Are Reshaping Manufacturing

    Machine Learning and Predictive Analytics Are Reshaping Manufacturing

    Regardless of industry or vertical, companies everywhere are encountering a new generation of customers with ever-evolving expectations. These new demands are forcing brands to redefine the way they do business.

    Today’s customers overwhelmingly favor the simplicity of subscription models, in which they pay a flat monthly fee for access to a product in the form of a service. For example, consumers no longer buy or rent DVDs; they subscribe to Netflix. And more prefer to use the services of Uber or Lyft over traditional car ownership. As these digital-age consumers enter the industrial workforce in large numbers, they are causing business models to be redefined, leading to an increasing trend toward subscription-based services in manufacturing industries.

    This shift toward a subscription-based business model in the manufacturing industry is being referred to as servitization, wherein manufacturers no longer strictly sell new products but instead sell access to and the outcome those products deliver. This new way of delivering services is forcing manufacturers to shift to subscription-based pricing models, where product-as-a-service is the norm. Manufacturers of complex industrial equipment, because they operate in a B2B environment, can attribute this shift to another major cause: Their customers are also dealing with complex operating paradigms, forcing them to improve productivity and capital utilization. In these scenarios, customers are looking to simplify their businesses and increasingly favor suppliers that can help minimize their risks in operating a profitable business.

    The full realization of servitization, which could take up to 15 years, especially impacts manufacturers’ after-sales service organizations (the service delivered after the initial sale of a product). In today’s current reactive, break-fix service model, the responsibility to maintain and ensure equipment availability falls on the customer. In a servitization model, however, manufacturers own the responsibility of maintenance and repairs and need to focus on maximizing product uptime, since revenue can only be earned when their products are available to generate output in the field.

    Machine Learning and Predictive Analytics in Manufacturing

    The use cases of machine learning and predictive analytics are as varied as the industries within manufacturing. However, there are a few common use cases that apply to most manufacturing verticals, typically grouped under terms such as smart manufacturing, industry 4.0 or industrial internet of things (IIoT).

    1. Predictive Maintenance: Predictive maintenance is the most well-understood and varied use case in most manufacturing industries. Here, data from process monitoring sensors such as temperatures, pressures, flows, vibrations and more are captured in real-time and used in pattern recognition software to detect the earliest symptoms of wear and tear predictive of eventual functional failures. Early detection and prediction can help prevent failures or at least plan for eventual corrective actions leading to minimized downtime. Downtime—especially unplanned downtime—can be a very expensive event, possibly leading to millions of dollars in losses. Some analysts estimate unplanned downtime in certain industries is worth $20 billion.
    2. Process Optimization: Process optimization, in which existing processes are updated and optimized based on historical data, is a critical use case, especially in industries such as power generation, oil and gas refining, petrochemicals and chemicals. In this instance, sensor data feed machine learning algorithms for yield and quality optimization of output components for different combinations and quality of input raw material feedstocks. This also helps with energy efficiency, thus improving sustainability and profitability for these process manufacturers. In the global airline fleet, for example, a 1% fuel savings would save $30 billion over the next 15 years.
    3. Supply Chain and Inventory Management: High levels of raw material, work-in-process and finished goods (e.g., replacement service parts) inventory are one of the highest contributors to inefficient capital utilization for discrete manufacturing industries. Using machine learning to improve raw material and demand forecasts while meeting dynamically changing production goals helps improve capital utilization and supports lean and just-in-time manufacturing production goals.

    In today’s customer-driven world, manufacturers no longer can rely on selling expensive spare parts and services, since these become costs of supporting a single-price subscription. This shift will require manufacturers to completely re-think how they operate—new organization structures and skilled resources, new incentive models, new KPIs to measure success and new processes replacing ones developed over decades and centuries. They will have to become data-driven organizations, investing in technologies to connect and track products, collect data and efficiently analyze these massive amounts of operational and service data, using technologies such as IoT, machine learning and predictive analytics. This will strain manufacturers’ existing organizations and IT infrastructures, necessitating investment in highly scalable cloud-based solutions to lay the foundation for a successful future.

    Manufacturers that embrace these changes will be the winners, while others will struggle to stay relevant. In fact, the ones who can successfully adapt to these paradigm shifts will be able to gain a significant competitive advantage over their competition.

    — Vivek Shah

  • GitLab Survey Surfaces Major DevSecOps Challenges Ahead

    GitLab Survey Surfaces Major DevSecOps Challenges Ahead

    A report based on a survey of 4,071 software professionals published this week by GitLab, a provider of a continuous integration and continuous deployment (CI/CD) platform, found that while appreciation of the potential value of DevSecOps best practices is high, the ability to implement those practices is uneven at best.

    According to the survey, half of the respondents reported that security vulnerabilities are discovered mostly by the security team rather than developers after code is merged and in a test environment. And, when cybersecurity professionals participate in a DevSecOps process, the survey found those organizations are three times more likely to discover bugs before code is merged. In addition, a full 90% of those organizations are more likely to have tested between 91% and 100% of their code early in the development process.

    Obviously, that’s better than discovering them after they’ve been deployed in a production environment. On the downside, however, nearly half of security professionals participating in the GitLab survey (49%) said they struggle to get developers to make remediation of vulnerabilities a priority. That challenge may reflect the overall maturity of the DevSecOps practices in place. For example, only 25% of developers participating in the survey rated their security practices as being good. That compares to only 20% of security professionals who rated their processes as good. Only 14% of respondents said they are relying on application security tools to test more than 91% of their code. A full 44% are using these types of tools to test less than a third of their code.

    Priyanka Sharma, director of technology evangelism for GitLab, said the survey makes it clear that DevSecOps is now officially a thing in the enterprise. However, only 44% of the survey respondents said that security vulnerabilities are a performance metric for developers in their organizations. As such, it’s clear there is still a long way to go before anything approaching DevSecOps nirvana is likely to be achieved. In fact, Sharma noted building and deploying more secure applications may require organizations to slow down the rate at which applications are being built, at least initially.

    The GitLab survey makes it clear most organizations are still struggling with mastering DevOps. Only 28% of developers said they feel good about their organization’s level of DevOps sophistication, while less than half (45%) said they have been able to implement continuous code deployment at least somewhere in their organization. That level of adoption suggests there still is plenty of opportunity to refine DevOps processes that are not fully ingrained. In fact, it appears most organizations are still trying to master agile development methodologies—more than half of the respondents said they employ Scrum (54%) as their application development methodology, followed by Kanban at 37% and DevOps at 36%.

    Ultimately, most organizations will have no choice when it comes to embracing DevSecOps. There simply are not enough cybersecurity professionals available to secure every application on their own. That means developers will need to assume more responsibility for cybersecurity, regardless of whether they like it. DevSecOps processes will be required to validate whether developers have implemented all the security patches and controls required. Anything less than that going forward will be deemed as nothing short of reckless—which, as any lawyer will gladly share, means much higher penalties for everyone involved.

    — Mike Vizard

  • Chef Brings DevOps to Windows Platform Migrations

    Chef Brings DevOps to Windows Platform Migrations

    Chef and Microsoft revealed today that they are working together to apply DevOps processes to accelerate the migration of Windows Server 2008 and SQL Server 2008 to more current versions.

    Announced at the Microsoft Inspire conference, the goal is to enable organizations to leverage Chef Enterprise Automation Stack (EAS), which includes an EAS Migration Accelerator for Windows that will scan existing .NET applications running on legacy Microsoft platforms to discover configuration and dependency details, then encapsulate that information as code in a way that enables the application to run on the latest version of a Microsoft virtual machine or as a container.

    Ewan Dalton, partner development manager for Microsoft, said there are roughly a half-million .NET applications running on platforms that are scheduled for end-of-life support beginning in January. In an ideal world, most of those applications would be modernized to be deployed on the Microsoft Azure cloud, said Dalton.

    Vikram Ghosh, vice president of business development at Chef, said rather than merely lifting and shifting legacy applications onto a new platform, Chef EAS will make it possible to employ DevOps processes to modernize how those applications are updated and maintained. Chef EAS makes it possible to, for example, scan, extract and package legacy applications and their dependencies, using source control repositories such as GitHub, and convert them into cloud platforms using pipelines such as Azure DevOps. Customers can deploy these application packages in Azure and run continuous security and compliance scans, added Ghosh.

    Chef EAS

    The biggest challenge many organizations face when trying to migrate applications is the developers who created the application haves long since left the company. As such, most organizations only have documentation, which is usually sparse. They then must determine whether it is worth modernizing the application or whether they should simply replace it. In cases where it is deemed that the business logic contained within that legacy application is still critical enough to continue running, they need to find a way to automate that process as much as possible.

    Longer-term, of course, most organizations will work to modernize legacy monolithic applications even further by slicing them up into a series of more manageable microservices. But many organizations are already running out of time when it comes to existing .NET applications. Once Microsoft ends support for the platforms they are running on, patches to address cybersecurity issues no longer will be provided as part of the standard licensing agreement. In effect, that means there is enough time between now and January to re-engineer an application. Chef EAS essentially throws organizations a lifeline to determine what they want to do next in terms of replacing a legacy application, said Ghosh.

    Of course, there will always be some subset of the IT community that will continue to run .NET applications on outdated Microsoft platforms. It’s also unlikely that any of those organizations will be embracing DevOps processes to maintain those platforms anytime soon.

    — Mike Vizard

  • Digital Transformation Drives C-Suite Discord

    Digital Transformation Drives C-Suite Discord

    In the sport of rowing, each crew member has to row in synchrony or the boat risks undesired turns and even potential tipping. It takes practice, communication and discipline for each crew member to raise their oar to the appropriate height and apply the appropriate power. Obviously, those crews who work best together are more likely to win.

    When it comes to winning at digital transformation, the same is true for the executive crew or C-suite. However, the drive to  digitally transform enterprises rapidly puts a strain across C-suite relationships.

    That’s the main takeaway from a new report published by the Financial Times Focus and business management software provider Apptio, “Disruption in the C-suite.” The report is based on a survey of 555 senior executives, about half in CxO roles and from Australia, Denmark, France, Germany, Italy, Japan, the Netherlands, Norway, Spain, Sweden, the UK and the U.S.

    The survey found considerable uncertainty regarding the IT department’s ability to be effective. In fact, 51% of respondents said they have concerns about IT’s ability to govern cloud adoption. And, surprisingly, less than one-fifth of companies using agile have defined performance indicators they use to track their results.

    Further, 47% of leaders surveyed agreed digital transformation has blurred work responsibilities throughout the C-suite. And the same number of respondents admitted digital transformation has exacerbated strategic differences among finance and IT leaders. In fact, 71% of finance leaders said the IT function needs greater influencing skills to deliver the change their business requires.

    According to the survey, while the CFO was the least deeply aligned member of the C-suite crew with the CIO, the lack of deep alignment with the CIO’s office and other C-level executives was shown to be disturbingly common. Only 56% of CEOs reported being deeply aligned with the CIO, the survey found.

    There are signs of hope. Eighty-seven percent of respondents in the U.S. said digital transformation has increased collaboration across C-level executives when it came to developing new products and services.

    Still, 63% of those surveyed said the IT function needs greater influencing skills to deliver the change their business requires.

    That lack of influencing skills—and lack of defined metrics to measure progress—has taken its toll. About one-third of CFOs said there is a lack of consensus among CxOs when it comes to how to measure the impact of new technologies.

    It’s interesting, 56% of respondents said they shift their IT strategy continuously as their technology leaders receive input from the business and customers. That’s hopefully advantageous, but with so much digital transformation discord among technology and business leaders within organizations, it’s a coin flip whether that’s good stewardship or blind steering.

    It’s absolutely vital that organizations get their digital transformation efforts right, and to also be able to do so successfully at the necessary speed. As we covered in the recent story, “Digital Transformation Vital for Business Survival,” 78% of organizations believe their company’s primary industry is evolving rapidly and digital transformation is necessary to survive the changes underway.

    Those businesses cited enhanced customer experience and customer relationship management, the ability to maintain competitiveness, enabling new ways of doing business, increased productivity, cost savings, increased revenue generation and enhanced product development.

    Few would doubt the accuracy of that assessment, nor that the entire C-suite crew must be in synchrony, understand each other’s roles and objectives and know where the entire team is heading. Otherwise, the entire effort is likely to veer off course.

    — George V. Hulme