devopsy.kinsta.cloud

Tag: developers

  • Perfect Sense Open Sources Gyro to Automate Cloud Provisioning

    Perfect Sense Open Sources Gyro to Automate Cloud Provisioning

    Perfect Sense has launched an open source project dubbed Gyro that provides an alternative approach to automating cloud infrastructure provisioning and management.

    Gyro was developed as an alternative to other open source projects such as Terraform and Pulumi, said CTO Jeremy Collins. It is designed from the ground up around a programming language that allows DevOps teams to define infrastructure as code, and features logic built into configurations to make it easier to create more precise workflows, he said.

    Adding logic to create equivalent workflows in rival platforms is more complex, Collins noted, adding the ability to add logic makes it easier to not only provision cloud infrastructure but also to roll it back when necessary.

    Perfect Sense developed Gyro to make it easier to manage the infrastructure for its Brightspot content management system (CMS). As such, Gyro can support multiple cloud computing platforms.

    In addition to making it possible to add cloud platforms to an existing configuration, Collins said it can be used to create custom commands and define multiple extension points directly within the Gyro language.

    Perfect Sense Gyro

    Perfect Sense developed Gyro to automate the provisioning of virtual machines. Since then, the company has extended its capabilities to add support for emerging cloud-native platforms such as Kubernetes.

    Collins said Gyro provides a single extensible tool spanning a broad range of DevOps processes, from provisioning infrastructure to discovering what services already exist.

    Despite the popularity of rival tools such as Terraform, it’s still early days in the adoption of infrastructure as code. Most IT organizations are a long way from standardizing on any one platform for automating the provisioning of infrastructure. In fact, it may not be uncommon for different DevOps teams within the same organization to employ different platforms for provisioning infrastructure.

    Gyro’s ultimate success will depend much on Perfect Sense’s ability to foster an open source community. The Brightspot CMS is used by the Los Angeles Times, Walmart, Mattress Firm, Univision, Sotheby’s and US News and World Report, so Collins said there is a base of support for Gyro on which to build a community. Perfect Sense is looking to build a community that will continue to extend the reach and scope of the platform by adding additional plugins.

    Regardless of the approach taken, as the number and rate at which workloads are being deployed on cloud platforms increases, it becomes critical for IT organizations to find a way to automate processes. It’s not clear to what degree those workloads will be provisioned by developers themselves versus traditional IT operations teams that have learned how to program. However, one way or another the provisioning of cloud infrastructure is going to be automated.

    — Mike Vizard

  • Compuware Extends Alliance With CloudBees

    Compuware Extends Alliance With CloudBees

    Compuware has become a premier member of the CloudBees Technical Alliance Partner Program (TAPP), as part of an effort to accelerate the adoption of best DevOps practices in mainframe environments.

    Sam Knutson, vice president of product management for Compuware, said his company has already developed six plugins for the open source Jenkins continuous integration/continuous delivery (CI/CD) platform. By joining TAPP, Compuware is signaling it will develop more modules in collaboration with CloudBees that can be employed on either the open source edition of Jenkins or the enterprise edition supported by CloudBees, he said.

    Compuware doesn’t plan to build a CI/CD platform itself. Rather, Knutson said Compuware is pursuing an “open borders” approach to CI/CD platforms that complement its Topaz tools for building mainframe applications. As such, IT organizations should expect to see Compuware allying with multiple providers of CI/CD platforms. However, in terms of overall adoption in mainframe environments, Compuware is seeing more instances of Jenkins than any other CI/CD platform, Knutson noted.

    Compuware also updated Topaz to provide a new editing experience that guides novice developers using COBOL, PL/I and JCL programming languages. It also now includes native integration with Eclipse integrated development environments (IDEs) and real-time COBOL and PL/I syntax-checking.

    Knutson said the adoption of best DevOps practices and CI/CD platforms are on the rise in mainframe environments, thanks mainly to the rise of digital business initiatives that require organizations to update applications more frequently. IT teams can choose to build those applications on distributed systems that then need to be integrated with existing applications running on a mainframe, or they can modernize the applications they have running on the mainframe, he said.

    The latter approach not only reduces the amount of technical debt any IT organization will need to manage, but it also results in a more secure application environment running on a mainframe, he noted. In fact, Knutson described building applications that duplicate functionality at the edge of a mainframe as “an unnatural act.”

    Knutson said IT organizations that employ mainframes are at varying levels of maturity when it comes to DevOps adoption. However, he predicts in 2020 there will be many more organizations highlighting their success building and deploying applications on mainframes using DevOps practices.

    Naturally, Compuware is not the only provider of mainframe tools trying to foster the adoption of best DevOps practices in mainframe environments. However, mainframe environments have employed waterfall processes for decades to build highly reliable applications. Many of the organizations that rely on those legacy processes are hesitant to abandon them if it means the application being deployed might be less stable or secure. At the same time, IT organizations that have mainframes are definitely under pressure to roll out application updates faster. As such, many of them have begun to incorporate agile programming techniques and best DevOps practices to achieve that goal. In fact, a recent survey published by Compuware finds organizations have increased deployment frequency an average of 41% for new mainframe features.

    Like it or not, change is coming to mainframe application development and deployment.

    — Mike Vizard

  • The Role of Developers in Digital Transformation

    The Role of Developers in Digital Transformation

    Developers are an integral part of digital transformation. They architect the modular systems that overcome legacy and build the applications and solutions that allow firms to deliver products and services in new and innovative ways. Yet, when it comes to business decisions, many organizations overlook their developer talent.

    Developers come from a variety of different backgrounds, but it’s safe to say that most have studied computer science, engineering or mathematics in some form. Coming from these disciplines means they are inherent problem solvers, so giving them a seat at the table when it comes to discussing business goals is, of course, beneficial.

    To ensure the business insights of developers can be unlocked, organizations should consider the following four points. 

    Encourage Personal Development

    More and more developers are actively taking an interest in improving their communication and leadership skills, recognizing that these are important tools for career development. 

    Soft skills, for example, are key to establishing relationships internally, as well as communicating to external parties. At any moment, stakeholders may want to understand the workings of product teams, or it may be the case that a customer requires more attention when implementing a solution. In the former scenario, developers must become advocates for the business and the way they work; in the latter case they must ensure that they take an empathetic approach to end users. 

    Whether it’s learning new programming languages, getting to grips with new technologies, or developing soft skills, developers relish the chance to grow. Organizations that offer learning and development programs internally will likely attract developers who are both apt and keen to involve themselves in other areas of the business. 

    Keep Things Agile

    Operating within an Agile framework gives developers and other members of product teams a chance to develop soft skills through scrum meetings. During a scrum meeting, each member of the team is given the opportunity to communicate openly about their challenges and devise solutions for other issues. This not only ensures a high level of transparency internally, it also allows business analysts to provide an accurate picture of progress to clients.

    Sharing insights and troubleshooting in an open forum enables those with a natural inclination for leadership to establish themselves as effective communicators. The limited size of Agile teams also keeps things personal enough that each team member’s feedback can be heard and considered by their colleagues. 

    Agile software development brings disciplines together, encouraging an exchange of ideas and an expansion of knowledge. This is in stark contrast to the Waterfall method, where siloed teams hand off work with little communication.

    With Agile, teams share responsibility, communicate and apply their disciplines in contexts outside those they are used to. In essence, Agile is the ideal way to establish a culture that enables learning and development on the job. This is much more practical than setting up a program that teaches soft skills and educates teams about other areas of the business, as these sessions can eat into work time and reduce productivity.

    Be Clear on Requirements

    It’s all well and good attracting the best and brightest developer talent, but in order to get the best from them, firms must be transparent about what is expected day to day.

    Firstly, efficient code delivered in a timely manner should be the goal of every developer. Testing and QA will, of course, reveal issues, and no one is perfect, but developers must be mindful of the impact inefficient or inaccurate code can have on a business. Workarounds may get you past a problem, but this is not best practice and leaves the business exposed should a client pick up on it–especially if the workaround causes more serious issues further down the line.  

    Fewer bugs or defects means scrum meetings can naturally focus more on strategy and new initiatives that might help grow the business. Organizations should therefore establish best practices and coding guidelines to reduce the temptation for workarounds, ensuring code releases are reliable and ready for the production environment. 

    Developers must also be able to comprehend the requirement to work with designs given to them by design teams, as these will align with customer expectations. Being able to dynamically incorporate client feedback into the development process is also key, particularly for those working with continuous delivery and continuous integration pipelines. 

    An interest in emerging technologies is desirable, as is an eagerness to innovate new solutions using them, but so too is an aptitude to leverage rather than re-invent solutions. This helps to keep costs down and ensures a maximum return on investment in existing solutions. 

    Keep an Eye on the Future

    Increasingly, the ease with which organizations can react to advances in technology will determine their long-term success. It is therefore in their interest to ensure developers have the freedom to learn new skills and explore new tools that might increase efficiency or unlock new offerings. 

    Advances in IoT, connected devices, augmented and virtual reality, AI and machine learning, blockchain and 5G networks are just some of the technologies opening up new challenges for firms and developers alike.

    Developers with the skills to harness these technologies will increase their employability, allowing them to secure better positions and salaries. They will also be well placed to advise on wider business goals, positing new use cases and solutions and fueling innovation.

    — Arun Ramachandran

  • How Can IT Admins Maintain a Grip on Secure Access?

    How Can IT Admins Maintain a Grip on Secure Access?

    Today’s IT environment is evolving at a rapid pace, requiring production environments to be highly scalable and elastic and requiring faster software release cycles and cloud adoption.

    As a result, there’s a broad move toward Docker containers to make software deployment faster, easier and more consistent across computing environments. Bundling an application and its supporting code, libraries, settings and assets into a single container enables the speed and flexibility that today’s business environment demands.

    At the same time, many large enterprises are also experimenting with creating internal startups, or labs, that are given latitude to innovate, housed under the company umbrella and resources. Similarly, some companies are hosting startup-like “innovation incubators,” where developers are empowered to think and work like startups, within the relative safety of the corporate environment. They can quickly test new ideas, using the “fail fast, succeed fast” startup mentality, without incurring the usual risks of an independent startup.

    It’s a new agile way of working that companies, in the race to innovate, are widely embracing. In fact, more than half of Fortune 500 companies have some version of these startup-like efforts housed within at least one business unit. 

    Replicating the unstructured movement of a small–say, six-person–startup is difficult to do within an enterprise environment. Nevertheless, the rapid pace, combined with the flexibility to innovate, is what the vast majority of developers desire today. But, it does mean that enterprises’ IT environments have to be ready to adapt.

    IT Administrators Under Pressure

    Developers on these innovation teams are often given the freedom to select the tools they’d like to work with. That can–and often does–include Docker containers, which adds to the complexity of the IT environment. 

    The environment that fuels developer innovation also creates additional concerns for the IT administrators supporting them. Developers can work so rapidly–creating hundreds of new servers each day–but often only do the bare minimum in terms of security. How can IT admins maintain secure access in the face of these changes? How can they keep track of who has access to what application and what data, when those applications and data are constantly changing? That’s a massive issue when it comes to compliance.

    As containers make enterprise IT environments even more complex, IT admins are under pressure to carefully manage access without slowing down development. The more complex the environment becomes, the more important it will be to have a holistic view of all of their underlying infrastructure, including the hybrid or multi-cloud environments that support platforms such as Docker and Kubernetes.

    Meanwhile, the enterprise executive team, often the CISO, overseeing both the development and IT departments is hard at work trying to satisfy the requirements of both groups. Of course, it’s in the business’s best interest to innovate and explore. But, all that innovation means nothing if the business is no longer secure and open to compliance concerns.

    Below are three steps executives should follow in order to keep their developers and IT admins happy.

    Consider the Developer Experience for Secure Access

    Off-the-shelf single sign-on solutions (SSO) may be good enough for business employees who need to access Outlook or Salesforce, but they aren’t robust enough for privileged IT users, like developers, who need to access secure environments. 

    Privileged access management (PAM) software sprung up to serve IT users, but even this isn’t a perfect solution, because traditional PAM tools are often too clunky to use, nonintuitive, or hard to configure. A bad user experience simply encourages developers to bypass PAM however they can, which is a compliance risk.

    Businesses need a way to deploy secure access very quickly, so they can holistically manage access to critical IT resources without slowing down development. That means choosing secure access solutions that are built with the developer’s needs in mind.

    Lean PAM solutions prioritize automated, instant access to secure IT environments with the click of a button, combining the convenience of modern SSO solutions with the security and fit of a PAM solution. If sysadmins have a great PAM user experience, they’re more likely to play by the rules. 

    Opt for Role-Based, Time-Bound Access

    To maintain the highest levels of security, access must be controlled on a role-by-role basis. Your rock-star in-house developers should be able to quickly spin up access to core IT infrastructure whenever they need it, while a third-party development contractor should only have limited access to those same resources for the time in which they are working in your environment–and no longer than that. 

    This is where we begin to see time-limited, credential-less secure access, enabled by ephemeral certificates, start to play a role in privileged access management. Ephemeral certificates are short-lived access tokens that are automatically generated and automatically expire–so access is granted only for as long as it is needed to authenticate and authorize privileged connections. 

    In other words, privileged access is able to move toward a just-in-time model, eliminating the need for passwords and clumsy credential management. IT users no longer need to authenticate using credentials at all–instead, based on predefined roles and security policies, they are granted access to resources only as and when required.

    Ultimately, ephemeral certificates help streamline access processes, ensuring that IT admins don’t have to worry about revoking access when access roles or needs change.

    Make It Easy on the IT Admin, Too

    Speaking of IT admins, it’s important to consider their experience, too.

    Admins want to give staff the best tools for the job without compromising corporate security. The friction between admins and developers begins when the developers feel that the tools admins force them to use are slowing down their work. In reaction, admins become frustrated when more unmanaged, unmonitored tools enter the corporate network, requiring more of their time to implement, configure or remediate if something has gone wrong.

    The right technology solutions make life easier for IT admins, too. That means secure access solutions that can be installed and deployed within a single day–not weeks–and that introduce automated routines and maintenance to eliminate manual work in the access management process. Accountability, in the form of session monitoring and logging, is also important. 

    Ultimately, it’s about giving IT admins some distance. They can retain the oversight they need to feel comfortable about organizational security, without needing to be on top of every single secure access decision in the organization. At the same time, developers retain the autonomy they need to work quickly without feeling like they’ve got someone looking over their shoulder. 

    By enabling rapid development, while keeping a watchful eye on enterprise security, enterprises can satisfy both their developers and IT admins, and ultimately, the business’s bottom line.

    — Markku Rossi

  • Can We Do Without DevOps?

    Can We Do Without DevOps?

    Recently, DevOps has received so much hype and every respectable company sees it as its duty to have a DevOps team on and running. It is considered to be so beneficial to any company that a non-technician scrolling down posts at any tech website would think of it as a universal remedy for all the corporate diseases ever possible. However, given that a definition of DevOps varies from company to company and no one exactly knows what a true DevOps team should do, isn’t there some misconception between the praise that DevOps has been receiving and the real output? Let’s dig deeper and decide for ourselves.

    Yet, despite the buzz around the notion, DevOps is said to be a working thing. It guarantees a company-adopter 200 times more frequent deployments, 24 times faster recovery and three times lower change failure rates, according to Puppet’s State of DevOps Report.

    That is why, to get a non-biased view on why one should “DevOps-ize” corporate processes, in our article we give the answers to the following:

    • What DevOps is?
    • What issues is it supposed to help resolve?
    • What does a DevOps engineer do?
    • What skills does a DevOps engineer need?

    All of these questions, when answered, will help us see why the industry has adopted DevOps as a regular practice, why your company needs to try it out and why we can’t do without it the way we used to before—or can we?

    What Is DevOps?

    According to the AWS, DevOps is the combination of cultural philosophies, practices and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. Well, this definition may not be as clear as the waters of Sardinia, so we’ll clear it up for you a little bit.

    The message is that once (before DevOps) the product release was slow and troublesome, while today, with DevOps practices in place, it almost reaches cosmic speeds and high-end quality. All through maturation of work approaches and practices–merge of development and operations–along with the automation, cloud technologies, virtualization and abundance of top-notch tools. DevOps culture to a certain extent enables developers to perform the work of the IT team, and vice versa, which breaks down the operational walls between the teams, eroding a “not my task” mindset at the same time.

    What Does a DevOps Engineer Do?

    If that’s what is happening today–programmers deal with the configuration issues and the IT teams code–why is a DevOps engineer on the tip of everyone’s tongue? Why come up with a new term if you can write some more new responsibilities into the dev’s/IT guy’s contract and leave the names as they are? The thing is, the transformation of the processes and roles was so substantial, that in time they merged into a completely new position, which is neither a coding IT guy, nor a configuring developer.

    Roles Before DevOps

    Developers

    • Built features, tried to merge separate pieces of code together (usually resulted in a huge amount of errors and ended up in a long and troublesome integration).

    Integrators or Production Facilitators

    • Known to have been engaged on huge banking/insurance projects.
    • The phenomenon had a limited application within the industry and this intermediary work piece was often shared between the devs and ops with varying success.

    IT/Operations

    • Fixed the developers’ mess and squeezed the available code (often requiring a lot of massaging) into the available infrastructure.
    • Supported tech life in the offices (repairs, tech support, configuration and security, etc.).

    Roles Today, Approximate Responsibilities Breakdown

    Developers

    • Specification-based code production.
    • Software components integration.
    • Troubleshoot, debug and upgrade of existing software.
    • Creation of technical documentation for reference and reporting.
    • Integrations implementation.

    DevOps Engineer

    • Infrastructure planning, testing and development.
    • Integrations implementation.
    • Updates and fixes.
    • Build tools to minimize errors and improve customer experience.
    • Develop software to integrate with internal back-end systems.
    • Production errors root cause analysis,
    • Investigation and resolution of technical issues, Level 2 tech support.
    • Script development to automate visualization.
    • Procedure design for system troubleshooting and maintenance.

    IT/Operations

    • Install and configure computer hardware, software, systems, networks, printers and scanners.
    • Monitor and maintain computer systems and networks.
    • Service issues and requests.
    • Technical support across the company.
    • Set up accounts for new users.
    • Repair and replace equipment as necessary.

    To sum it all up, a DevOps engineer is a so-called “centaur” performing duties of a system administrator between coding sessions. His/her primary objective of the project is to find a solution that will make product deployment fast and efficient and people’s (devs and ops) lives easier.

    What Skills Does a DevOps Engineer Need?

    According to the Qulix’ practice, an ideal skillset for a DevOps is:

    • A technical graduate.
    • Intermediate or advanced English.
    • General programming skills.
    • Proficient PC-user knowledgeable about networking, Git, Linux, Docker, Nginx, Bash.
    • Strive for constant perfection and thirst for the new.
    • Curios, with inner drive to get to the bottom line, enthusiastic.
    • Strong work ethic and time management skills.
    • Open and a great team player.

    These will do for a start. At the same time, within the same company various departments may require from their DevOps engineers to have a command of different technologies. For example, another department of ours expects from their candidates to know TCPIP, DNS, Nginx, Tomcat, Git, Bash, Groovy, Ansible, Docker, Ubuntu, Debian, Macos, Gradle, Maven, CI/CD.

    As you can see, an ideal fit for the position of a DevOps engineer within a specific department is something rare. All because DevOps engineers have to have so much on their plate, both from technical and soft skills perspective. Why? First of all, as a system administrator to a certain degree, a DevOps engineer has to operate numerous technologies, that sometimes far outweigh the number of those a regular developer uses on a daily basis. In this connection, I once asked a friend of mine working in a DevOps team, “Of all the difficult things that you have to deal with as a DevOps guy, which one is the most difficult one?” And his response was “Everything.” 

    The “everything” of my friend needed further explanations, for which I headed to another DevOps engineer of Qulix Systems, Denis Golovnev. He told me he opted for a DevOps position because he wanted to get to know the whole SDLC closer and in depth, as “this position requires a 360-degree knowledge of the SDLC processes.” DevOps guys are among those few specialists who stay on the project from start to finish, to maintenance. That is why “a DevOps engineer won’t only have to dig deeper into his/her own area of knowledge, but also target adjacent spheres to see how the product is created and how his/her actions can create more value for the client,” explained Golovnev. Thus, this made the tech part clear to me.

    What about soft skills?

    “The most difficult thing about DevOps is to arrange the processes in a manner that will suit everyone; the one that will encourage the initiative and individual decision-making process, to a reasonable extent,” said Golovnev. “To achieve that, highly developed soft skills are a must to get to the root of the problem and enable an engineer to outline clearly his/her point of view to everyone.”

    On the other hand, DevOps team will inevitably face both technical and organizational issues, which should not be confused.

    “One should not try to settle human-related issues through technical means,” said Golovnev. This is another reason why a candidate without highly developed soft skills is very unlikely to get the position. Soft skills are the absolute killer thing for a DevOps candidate.

    To Wrap It Up

    We’ve been gradually migrating from slow and troublesome product releases and delivery of separate work chunks to a speedy, orderly and consistent performance. Most definitely, this transition isn’t the consequence of DevOps practices implementation alone. But without it, without the culture of speedy collaborative delivery, dynamic issues resolution and ultimate automation, which are typical of the DevOps philosophy, the shift would be impossible.

    Furthermore, the revolution starts from minds, whereas the means comes later. If a typical DevOps engineer is, as according to Golovnev, “the one in love with his/her job, insane as to automate everything within his/her reach, get to the core of any constrain that impedes fast product delivery or reduces effectiveness,” no wonder we, as consumers, and the whole industry need them. Together with the outstanding tools and technologies, a DevOps engineer is a soldier that, in 100% of cases, shoots to kill (any production constraint).

    One issue, however, remains unclear. With all the variances as to what true DevOps means even within the same company, how will we reach a unified DevOps definition? Most definitely, some unanimity would be useful for the candidates that try to land the position but end up rejected due to the above-mentioned differences in DevOps visions among the companies.

    On the other hand, lack of unambiguity is justified due to a wide range of technologies as well as different approaches used by different companies. So far, skillset variance will stay a key problem in regards to DevOps hiring. Although our main question–can we do without DevOps?–is out of the question.

    — Veronica Chizh

  • Accenture Cloud Simulation Platform Advances DevOps

    Accenture Cloud Simulation Platform Advances DevOps

    Accenture has launched a cloud simulation service through which DevOps teams can better determine which workloads will run best on different cloud computing environments.

    Kishore Durg, growth and strategy lead for cloud at Accenture Technology Services, said myNAV is a cloud service created by Accenture that leverages machine learning algorithms and other forms of artificial intelligence (AI) to leverage a knowledge base Accenture developed during its decade-plus working on cloud projects. DevOps teams can leverage that expertise without requiring Accenture personnel onsite to account for deployment variables such as technology infrastructure, types of application workloads, data, operational models and even business outcomes before committing to a specific cloud computing platform, he said.

    DevOps teams can also employ myNAV to engage in canary testing of application workloads, Durg added.

    DevOps teams employing myNAV are guided through a three-step process that starts with scanning and assessing the existing infrastructure, application and data landscape to recommend the most appropriate cloud architecture. An AI engine developed by Accenture then accesses a knowledge base curated by Accenture to come up with a recommended enterprise architecture. Finally, simulation and testing tools are applied to make sure the IT environment will scale as required.

    At the end of the process the DevOps team is presented with a bill of materials that resembles the bill of materials that might be presented when building a house, said Durg.

    Despite commodity pricing models, not all cloud computing platforms are created equal. Various attributes of application workloads lend themselves better to different attributes of cloud computing platforms. It’s not uncommon for IT organizations to find themselves rolling back applications from a cloud platform after encountering performance issues or discovering that cost of running a specific type of application on a cloud exceeded their available budget.

    Durg said 3-D visualization tools make it a lot easier to determine which cloud platform to employ and derive the maximum value from that investment by ensuring the cloud environment chosen is optimized for that application workload. Accenture research suggests that as many as two-thirds of organizations are not getting the maximum value from their cloud investments, he noted, and most of those issues stem from the cloud platform being poorly configured, added Durg.

    Whether by accident or deliberate, most IT organizations are employing multiple clouds to build and deploy applications, but their cloud platform selection process is often haphazard. Developers often default to the cloud platform that is easiest for them to access, which could create cloud platform lock-in. Cloud simulation platforms make it easier for the entire IT team to better appreciate the trade-offs in selecting one cloud platform over another.

    Of course, most IT teams would like to unify the management of multiple clouds under a single console through which they can more easily play one service provider off against another using a hybrid cloud computing model. Until that day arrives, however, most IT organizations will find it advantageous to know as much as possible about any cloud platform before making a decision they may come to regret.

    — Mike Vizard

  • And the Builders Shall Inherit the Earth: The Democratization of IT

    And the Builders Shall Inherit the Earth: The Democratization of IT

    The democratization of IT is happening, and vendors need to recognize that if they want to survive

    Just back home from KubeCon/CloudNativeCon in San Diego, which can only be called a force of nature. I was joined there by more than 12,000 other folks to discuss, listen and learn about all things cloud-native and open. Once again, I was blown away by the passion of and buzz generated by this community. What is driving it? I think I figured it out: The developers and builders shall inherit the earth. It is the democratization of IT.

    What I mean is that a fundamental shift has taken place in the IT world. Developers, architects and builders are in such high demand and are now the alpha predators of the food chain. They are the ones demanding and deciding what tools they use, how they build and what infrastructure they use.

    Smart vendors are recognizing this and penetrating large organizations by giving these builders the tools they absolutely will love working with. In many cases, these tools are free and open to use in non-enterprise versions. The vendors also have DevRel teams and marketing that cater to these builders and developers, rather than traditional marketing and sales.

    The fundamental shift is that for the nearly 30 years I have been in IT, the mantra has been to talk to the “decision-makers”—the CTO, CIO, and VPs who approved and paid for purchases in IT. Entire marketing strategies and sales were built on this. Lead generation campaigns focused on reaching executives, while salespeople vied for position by taking these people to dinner or golf and shmoozing them. Content was created that spoke to the executive class. Very few folks tried to focus on the practitioner; after all, they didn’t make the decisions; they didn’t hold the purse strings.

    That way of doing business has all changed. Yes, there are some dinosaurs out there who don’t hear the meteor speeding down just yet. But by and large, companies that are thriving in this new era of open solutions, open core and free software are doing so by following a new way: They cater to the developer/builder class. They listen to what this group wants and provide it to them. After that, they make sure tools evolve to meet the needs and wants of the builders. They have figured out that when they deliver delight, these people will tell their organizations that these are the tools they want to use.

    I heard Shlomi Ben Haim, co-founder and CEO of JFrog, call this the “democratization of IT.” This, along with DevOps and the cloud, are the megatrends driving transformation. But I also spoke to dozens of other vendors at the show. Maybe they didn’t call it that, but they instinctually recognize it.

    The world wants software-based everything. The people who are building the infrastructure, writing the code, testing, deploying and securing this software are demanding that it be open, free and cloud-native. They want to use it for a while before they will invest in the paid, enterprise versions and functionality. But once they do, their organizations buy in.

    The buying cycle starts off with the use of free software—maybe an employee whips out a credit card for a small monthly fee to purchase the SaaS version. But it ends with an enterprise purchase.

    The democratization of IT is going to work its way through our entire ecosystem. Content is going to be catered not to the executive suite, but to the practitioner. Lead generation programs aren’t going to focus on CXOs, but on people who will actually use the product. Sales strategy and tactics will reflect this as, too. More dev relations, less golf.

    Another driving force of this market is the new generation of people who are building and deploying. They don’t have an allegiance to the whales of yesteryear. They are fresh and willing to try new things if it gives them the functionality they want. Don’t give me that millennial, “OK, Boomer” crap, either.

    These folks work hard, and they are passionate about what they are building. They want open. They are used to having free tools and they are the new boss.  Maybe not the same as the old boss, but they are not fickle and want to choose the tools they work with. They will not be dictated to by a generation of folks who built during a different time with a different way of doing things. Successful vendor organizations need to realize that and work with these people.

    Of course, executives still set budgets and have to sign off on larger or more expensive purchases. They will need to be satisfied. But increasingly, it is not going to be the vendor who does that. They will rely on their builders and their developers to choose their tools and products. If you are a vendor and are not operating this way, look up to the sky because you just may see a large fireball coming your way.

    I, for one, think this is a good thing. It is time for the democratization of IT. Let the builders inherit the earth.

    — Alan Shimel

  • Developers Are Gaining Clout, and We Need to Pay Attention

    Developers Are Gaining Clout, and We Need to Pay Attention

    I’ve been watching the ascent of developers for quite some time. A few years ago, I wrote an open letter to developers in which I noted their power and collective influence over the direction of technology across industries. As creators of our digital future, developers hold incredible power—and with that power comes great responsibility.

    Developers now directly influence technology decisions within their organizations. They have achieved widespread recognition for their expertise and, as such, have frequently acquired a broader role in their company’s digital trajectory.

    While developers have always been first and foremost in feature and functionality development at the Cloud Foundry Foundation, we’re starting to see this approach bubble to the surface across the business landscape and in other open source communities. Cloud-native technologies often focus on operators, but it’s just as important to empower developers.

    If our goal is, as it should be, to enable developers to be more productive and give them the freedom to create more applications to production as quickly as possible, a developer’s workflow needs to be seamless and intuitive.

    Developers Need Widespread Support

    The long-tail impact of developers gaining a seat at the table and influencing technology decisions is a positive shift that demands widespread support. It’s critical that we recognize the important role developers play today and give them accompanying responsibilities to meet our common goals.

    Think about who is creating the software that’s changing how organizations operate and interact with customers: It’s the developers. Developers, above anyone else, know the technologies that make them most productive and impactful. Putting them in the driver’s seat is paramount because we all benefit when they are given space and time to be as productive as possible.

    Enterprises of all shapes and sizes are taking notice and shifting strategies as a result. Indeed, a significant majority of organizations are empowering developers with the freedom to choose the tools they use. In our most recent research, we found that 59% of respondents said their company is giving development teams more authority to choose their tools.

    Perceptions Are Evolving

    It’s no coincidence that this change is happening when software development becomes more critical for companies across all industries. Organizations realize the biggest hurdle to improving application development productivity is culture. More than a third (37%) of survey respondents feel that way today. We’ve been tracking this sentiment since 2016 and only a quarter of respondents felt that way then.

    Just three years ago, 39% of respondents said technology was the biggest hurdle for their organizations to overcome. That number has dropped to 29% today.

    That’s quite the inverse from 2016, and it indicates the levels at which software development is becoming a greater priority for businesses. As such, it’s increasingly common for organizations to give developers resources and influence to shape the direction of their business.

    Let’s not become complacent. We all need to double down on giving developers the best possible experience. It’s the developers who are driving transformational change in our organizations. The more power we give them to do so, the better off we will be as a result.

    — Abby Kearns

  • Harnessing the Power of Developers

    Harnessing the Power of Developers

    In our fast-moving digital economy, organizations across just about every industry are faced with a stark reality: to remain competitive and deliver the best possible customer experience, they must evolve continuously. The fintech industry is a great example of this–the sector’s growth and focus on excellent customer experience has been driven by external developers rather than incumbent players.

    For many companies, particularly in the service industry, improving customer experience now means developing new apps and services that will maximize the customer journey, engender deeper trust and secure customer relationships for the future.

    The aim is to continuously produce innovations that create delightful customer experiences, which in turn will drive ROI. In its 2019 Technology Industry Outlook, Deloitte highlighted the fact that the “democratization of innovation” is set to be a key strategic factor in the coming years. As cloud infrastructure makes it easier to innovate at speed, “medium and small enterprises can harness powerful capabilities once limited to a select few.”

    That might be a new SaaS application, for example, or the implementation of emerging tech such as AI or VR–anything that helps the company provide a more efficient or accurate customer service. A simple example could be integrating complementary, adjacent solutions to add additional value to end customers.

    Companies need to innovate in order to create unexpected functions and capabilities that will delight. But how do companies go about making that a reality? In a nutshell, there are two groups that can help you innovate: your own developers and the wider developer community. Having the right people involved and the right programs in place for both of these channels will allow you to scale and deepen your innovation more effectively–and ultimately create experiences that your customers cannot live without.

    The more you engage with developers inside and outside your organization, the faster you can accelerate your time-to-market for new innovations and, crucially, ensure that those innovations meet real customer needs.

    In-House Developers

    Building an effective in-house development team to meet customer needs is about more than just hiring the right computer skills. Companies need to aim for a fearless, fail-fast culture that lets teams go above and beyond in answering customer needs. This need not apply to all developers–there will be some focused on refining the core product set, for whom fail-fast may not be the ideal working model. However, in the pursuit of unexpected offerings that will delight customers, a healthy attitude to both fail-fast and conventional development is essential.

    Often, organizations are held back from being the best they can be by ingrained, deep-rooted cultures. The power of “the way we do things ‘round here” can be hard to crack, but good leaders must help staff buy into change as an ongoing process that will help them and the business to succeed in the long run.

    That’s where the concept of experimentation and fail fast comes into play. In these environments, developer teams are given permission to try things out without having to go through multiple rounds of approvals and senior buy-in. That means they can go from an initial idea to a fully testable concept in, say, weeks rather than months or years. It also means they can run their blue-sky ideas through a crash course of reality, bumping up against unforeseen problems–what some people might consider failures, but I think of more as learnings–without being penalized for it.

    When developers are given this permission to get ideas off the ground quickly, the benefits to the organization are obvious. Improved access to innovation; a greater chance of discovering more effective ways of working; and a supportive, forward-looking culture that helps to enthuse non-technical staff as much as developers themselves. The same is true for customers–they will benefit from innovations that improve their experience, surprising and delighting them with the idea they didn’t know they needed, but which exactly addresses their needs.

    Practical Considerations

    There are other key issues to address, particularly senior buy-in and customer-centricity. First, it’s essential that developers know their work is valued by senior leadership. Senior leaders need to trust their experts and not just allow but also champion the fail-fast model if the company is to benefit from the successful innovations that come out of it.

    Second, developers need to work in close communication with customer-facing teams to ensure their efforts are directed toward innovations that will translate into improved customer experiences. In other words, it’s important developer teams innovate with the company’s core goals in mind–not just for the sake of it, however tempting that might be.

    There are also pragmatic issues to be addressed, such as ensuring your APIs or SDKs are well developed, and there are good documentation/guides to help use these APIs. This is required for both in-house and external developers.

    External Developer Networks

    Having a wide network of development partners can also help rapidly scale innovation and deliver solutions that exceed customer expectations with speed. By building a community of great minds around the mutual benefit of market-ready innovation, organizations can unlock far more valuable projects, with positive effects for them, their customers and their partners.

    An effective developer partnership works on the basis that there is a symbiotic relationship where each side has something to offer to the other. For example, the developer partner may come from a smaller company who has specific expertise and can benefit from the financial support and expertise of the larger organizations. While both sized organizations can benefit from the diverse thinking, agility and challenger mindset of the developer partnership. Whether you’re a large company looking to fast-track customer-centric innovation or a small company with a great customer-centric idea that needs a boost onto the next rung, a healthy developer network can be highly beneficial.

    As an example, the accounting industry is currently undergoing a major cultural change, with accountants increasingly seeking to provide customers with value-add strategic services to maintain their competitive advantage. Technology is driving a consultancy-first service model. Accountants have access to more data than ever before, and as a result they can help clients to make effective business decisions based on new analytical insights.

    However, making the jump to effective consultancy requires new tools and innovations to turn raw information into usable insights. By working in partnership with a network of cutting-edge developers, accounting software providers can help to conceive, road-test and launch user-friendly solutions.

    The value of developer networks is also evident as you look at domain specific needs that might span a particular industry or a particular region. One company may not have the expertise or bandwidth to do it all–but by building effective communities of developers, an organization can expand their reach to tap into niche areas of expertise. It also gives the company the ability to deliver innovations more rapidly. Every company has a limited set of resources, and additional developer networks can help scale this innovation. For the developers, the value lies in reaching markets and customers they may not previously had access to.

    Taking Innovation Out of the Lab and into the Market

    Whether your company uses in-house developers or a partner network (or both) the core goal should be to hone ideas into realities through collaborative working practices. When developers and customer-facing teams understand one another, they can achieve great things.

    It’s an exciting time in the industry. Technology is evolving faster every day, solving more problems and opening up new possibilities. For businesses of all varieties, harnessing the power of developers should be a core priority. It’s not a question of pursuing innovation for the sake of it–it’s about taking practical steps to ensure you maximize the positive impact of tech on your customer experience.

    — Shivani Govil

  • Red Hat Streamlines Operating System Update Cycle

    Red Hat Streamlines Operating System Update Cycle

    Red Hat is looking to make it easier for DevOps teams to absorb leading-edge innovations as they are slipstreamed into a new distribution of CentOS.

    CentOS is a distribution of Linux based on a fork of Red Hat Enterprise Linux (RHEL). The team that oversees CentOS operates independently of Red Hat. That team in collaboration with Red Hat is making available an additional distribution dubbed CentOS Stream, through which a continuous stream of content will be updated several times daily.

    Mike McGrath, senior director for Linux engineering at Red Hat, said those innovations eventually will find their way into RHEL, but until then developers who want to build applications using those features as they become available can use CentOS Stream.

    This latest distribution of Linux from Red Hat is intended to act as a bridge between Fedora, a distribution of Linux through which Red Hat makes available experimental technologies, and RHEL, he said.

    McGrath said developers have been asking for a more stable distribution of Linux that provides access to innovations that are likely to be incorporated in RHEL, which so many IT organizations today deploy in production environments. CentOS Stream will make it easier for developers to take advantage of those new capabilities a lot sooner than they can today, he noted.

    CentOS Stream will be maintained in parallel to CentOS, which means organizations that have decided to standardize on CentOS are not going to be impacted by updates to CentOS Stream.

    As more organizations subscribe to software, version numbers associated with any software platform are becoming less relevant. Many DevOps teams especially want to be able to take advantage of new capabilities within the context of a continuous integration process when and if they see fit, rather than waiting for a formal update of a piece of software to be released.

    It will be interesting to see how many IT organizations embrace CentOS Stream at a time when many of them are under increased pressure to build innovative applications faster. In many instances, those innovations are dependent on features and capabilities embedded in the operating system, so waiting for those capabilities to show up in a major RHEL upgrade isn’t especially helpful. Many developers want to be able to exploit those capabilities the minute they are certified to run on RHEL. In many cases, developers are gaining access to those features only a few short months ahead of time whenever a preview edition of the next version of RHEL is made available.

    Eventually, every software platform provider will need to come up with some similar approach to CentOS Stream to provide developers with early access to new capabilities. In many cases, developers already have access to next-generation features if they have a close relationship with the platform provider. However, the process for making new capabilities available to developers remains haphazard at best.

    — Mike Vizard