devopsy.kinsta.cloud

Tag: devops

Microsoft Snaps Up GitHub for $7.5 Billion

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

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

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

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

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

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

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

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

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

— Charlene O’Hanlon

June 4, 2018
Continuous Integration Principles You Can’t Afford to Ignore

After recognizing the potential benefits from both continuous delivery (CD) and continuous integration (CI), many organizations have started implementing DevOps in their business operations. However, even today, many organizations don’t completely understand the core principles of continuous integration. Many people think that they are performing continuous integration as part of the DevOps implementation, but they actually aren’t.

DevOps and continuous delivery are the market disruptors today and are providing businesses with a massive competitive advantage. Continuous delivery is developed on the tried-and-true practices of continuous integration. The companies that seek to recognize the advantages of continuous delivery have many times failed to completely understand CI concepts.

The companies that perfectly carry out the continuous integration are following some basic rules. The working copies of developers are synchronized with the shared mainline once in a day or, most often, several times a day. An automated build verifies each integration to locate errors as quickly as possible.

The CI process has been designed for embracing failure where developers can fail fast and fail very often, so they can locate and resolve errors quickly and early. The companies that don’t follow the above mentioned steps are termed as non-followers of continuous integration.

Implementing Continuous Integration

Continuous integration is a practice the development team follows and it provides real benefits for the whole organization. The engineers who are responsible for executing the practices of continuous integration want to attain those benefits and follow the most advanced practices their peers follow.

Most often, companies understand how the teams implement the practices of continuous integration and then make decisions depending on this. The companies that do not follow CI principles are likely to face problems delivering functioning, crisp builds regularly. The members of the team will become disenchanted overtime and the initiative will lose momentum.

People who don’t want change will get back to the traditional practices if they don’t observe any evidence of the advantages of change. You will have various problems, such as your team losing faith in implementation, unnecessarily wasted time, error-laden builds and projects that must be restarted.

The organizations that lack the proper implementation of CI practices often face the cultural barrier problem. Engineers possess expertise in resolving the technical problems, but continuous integration requires a shift in culture and this is hard to achieve.

You can get a CI tool and check almost all the boxes that apply to what continuous integration represents, but if you want to succeed with continuous integration, a transformation in how you work is needed.

Instead of depending on tools for detecting problems such as a continuous integration error, the information can be automatically and independently verified through smart contracts on the blockchain, which is the technology behind cryptocurrencies such as the bitcoin wallet. The team will have a tough time implementing CI if its culture doesn’t change.

Continuous Integration Principles

Continuous integration depends on several major principles. Let’s deep dive into each one of them.

Prior to checking in to source control, code must be built and tested: This can be done by compiling the build locally by yourself and then verifying that the stats pass. You can also depend on a VC/CI system that can carry out pre-commit builds. You can also utilize pre-commit hooks in svn to achieve something similar.

Everyone should work toward the output of the CI system: The project managers and testers are also included in that. They must work in a way that they are confident on the working of build at some point and thereafter, every commit is an improvement. They should feel proud to showcase every build’s results to the entire project team and must react quickly for any reason.

Functional automated tests must be carried out as part of the CI process: If you have the automated regression tests suite, chances are it is not difficult to hook them up to the CI system—and in the long run, it’s definitely worth it.

Unless you are fixing the breakage, never check in on a build that’s broken: Post the original breaking commit. If you have numerous commits to a codebase, this leaves some issue in your CI system. If your commits aren’t coming fast and thick, this implies you are not reacting to the failures of your build and this is considered a serious issue. Also, the reason for the occurence of original breakage can be much more difficult to determine if other check-ins were done since the original one which broke the build.

Make the check-ins exactly fit your needs: You may hate waiting for a long time for the compiling of a simple check-in build when you want to know whether you violated some major rule or have broken the unit tests. Make the check-in builds lightweight and run your code coverage and unit tests only. Chances are, you need not run all your analysis tools, code inspections and the automated functional tests every time there is a check-in. So, it’s better you keep the check-in builds light.

Respond to the feedback: The CI system is a tool used to help steer quality and improvement as much as anything else. So, it should never be ignored. Nevertheless, it is easy to not pay attention to your CI system if the feedback is irrelevant. Working closely with the build team and the other members of the project is the solution, ensuring the build feedback is relevant and targeted.

Other considerations: Never leave a broken build as it is; fix build failures as soon as possible. Also, every check-in must possess some value. Otherwise, what’s the need for doing it? Every check-in must be an enhancement of the last one. Here, the enhancement can be stated as an increase in code coverage, a bug fix or a new piece of functionality. Ensure you put it in your commit log if the improvement can’t be measured easily.

Conclusion

Continuous integration can be considered as a development practice that needs developers to embed code into a shared repository many times a day. The automated build validates each check-in, thus enabling teams to detect problems very easily. Continuous integration helps you build a solid foundation and enhances visibility enabling greater communication.

— savaramravindra

June 4, 2018
Using Blockchain to Advance IoT

Imagine two disruptive technologies come together to democratize transparency and connectivity in the tech world. That’s exactly what’s happening with blockchain technology, once synonymous with powering cryptocurrencies including Bitcoin, has the potential to be a disruptor in a number of verticals and the internet of things (IoT), with blockchain addressing key IoT security concerns.

About Blockchain

The blockchain is the transaction recording distributed computer ledger. Its major use traditionally has been in securing the transaction of cryptocurrencies over the internet. Different users have their own wallet, which serves as a node in the blockchain network connected to the internet. Transaction messages can be sent in an encrypted form, which acts as a digital signature and does not allow tracing of the user’s wallet or tampering with any data stored there. Each wallet is controlled by a public key and a private key. To initiate a transaction, the user broadcasts an encrypted message in the network using the private key and the message can be decrypted by other network members using the public key. To materialize a transaction between the users, it needs to be approved by the majority of the nodes to help detect any fraud or data-breaching attempt before finalizing the transaction. So, it is the public that is controlling transactions, unlike banks or other financial institutions.

About IoT

IoT is a concept of embedding everyday-use items with sensors and other electronic components for enabling connection and data exchange between these objects. It is growing at a fast pace, and internet-connected devices increasingly are being used in different industries. IoT has made life easier, with smart devices that can be controlled using mobile apps, and can even be programmed using artificial intelligence.

To function most effectively, IoT devices generally take user information, which means there are security risks. As a result, IoT development is lagging and IoT vulnerability to cyberattacks due to the lack of a robust centralized security model is a real concern.

Blockchain and IoT Complement Each Other

It is evident from history that whenever two complementary technologies merge, new, dynamic products are formed. The greatest advantage provided by blockchain technology is security of data, which happens to be the most difficult challenge faced by IoT. Immutability, decentralization and transparent data-sharing are the most significant advantages of blockchain that are lacking in IoT, and the IoT community wants to integrate these features for data security. User privacy can be maintained in cases where desired by grouping and classifying anonymous individuals or groups under an über Do Not Track (uDNT) system. The smart IoT devices can use the data and information stored on blockchain efficiently for performing various tasks. Blockchain also can help in IoT scaling as it struggles for growth.

Blockchain also benefits from being paired with IoT, as it is showing its worth in a new domain of application apart from cryptocurrencies that most would consider to be much more useful on a daily basis. Thus, the two disruptive technologies complement each other and can reap dynamic solutions for different industries when used in conjunction.

Security of Data is Enhanced

IoT needs a robust centralized security model to grow in acceptance and use—something blockchain technology and the cryptographic processes driving it can offer. More and more offline objects are being converted into online assets with IoT, thereby increasing the risk of cyberthreats. Businesses, therefore, need to plan strategically for the protection of not just the smartphone and desktop computer, but almost everything connected to the internet. The objects in IoT ecosystem can act analogous to the nodes in blockchain technology, thus making connected home, connected cars and other connected devices more reliable and secure with blockchain-based IoT.

Data Analysis and Intelligent Use of Data

By leveraging other technologies such as artificial intelligence (AI), businesses using IoT along with blockchain can uncover useful insights through data analysis and understand the consumer requirements and market trends in a better way.

User Interconnectivity is Enhanced

With the transparency provided by blockchain, the users can make the best use of the interconnectivity provided by IoT to the networks of smart devices. IoT users can connect with each other in more beneficial ways and discuss their issues and queries more openly to gain different insights.

Privacy and Integrity of Data is Increased

With the increased amount of data, the privacy of data is gaining more importance as powerful IoT companies are tracking almost everything about the users. Lack of proper encryption and data leakage not only put individuals at risk, but also makes industrywide business models vulnerable. Using blockchain with IoT not only makes data immutable, tamper-proof, verifiable and transparent, but the data also is encrypted correctly to preserve user privacy.

Transactions are Fast and Small

Certain companies plan to incentivize users with small rewards for sending data, such as by paying a percentage of their electricity bill, providing points or paying the user, thereby creating a new route for earning a passive income. However, with banking fees often outweighing the transaction itself, this idea currently is not feasible. Blockchain can help to solve this problem.

Transactions can be Automated

Using blockchain, the services and transactions made by IoT devices can be automated without human interference. For instance, an autonomous car would be able to pay for a refill, parking fees or mechanic fees by enabling smart contracts that follow the “IFTTT (IF-this-THEN-that)” command.

Infrastructure, Operational Costs are Reduced

Using blockchain, the infrastructure for projects can be outsourced and the cloud side of IoT can be handled by the network. The need of any middleman and the legal and contractual costs, along with the maintenance, update, and supervision costs are cut down. This leaves ample time and money with the companies to focus on the hardware, application, and innovation side of things.

How will Blockchain Combine with IoT?

In the near future, a conventional, centralized model will not be able to manage the data produced by IoT, so, the decentralized approach of blockchain technology will be necessary for data management to avoid data tampering, single-point failures and third-party interference. The entire data is shared across the network like a shared ledger updated in real time.

Comprehensive Blockchain-IoT Approach

To face growing competition in the market, businesses that adopt the blockchain-IoT approach earlier are bound to be more successful. A suitable blockchain-IoT app development company is one that has the following characteristics:

Domain-specific knowledge: Data intelligence needs to be applied along with the knowledge of specific domain to derive the warranted performance or result from investments.

Development intricacy: With the growing business needs and customer expectations, businesses expect a high-performance computing infrastructure. Thus, the company should be able to deal with the business operation and data processing complexities.

Data management on a large scale: For storing and processing large amounts of data, AI and machine learning need to be used. The company must have a hands-on experience in data handling and processing using these techniques.

Final Thoughts

Blockchain and IoT together can be a game-changing technology for the mobile world. Many companies will benefit from the added security and automation offered by blockchain. In the very near future, we are going to see how blockchain solutions will rule the commercial IoT world and futuristic companies will undertake the process of developing and implementing it themselves.

— Juned Ghanchi

June 4, 2018
6 Steps to Take DevOps to the Next Level

Enterprises should be winning at DevOps and reaping the rewards of their digital transformation initiatives. After all, DevOps is not new. Its practices, technologies and processes have been widely accepted for years. Agile techniques, which underpin DevOps, are not new, either. Similarly, digital transformation may have started as a “tech solution” but it is now recognized as a C-suite imperative.

So why are the majority of business underexploiting their potential? Enterprises stand on the brink of a new era of opportunity heralded by 5G, the IoT and AI. So, how will DevOps rise to the new challenge of increased speed, scale and complexity?

Time to Worry?

Test automation levels in organizations speak volumes. Automation is an important marker of DevOps maturity and an indicator of how well a business can compete on quality at speed. So, it is a little worrying that software teams continue to rely on manual processes, with just 16 percent deploying automating common test activities.

It is often observed that DevOps requires cultural change to really take hold. Motivating and retaining top talent is as important to the health of a DevOps implementation as the latest platform or framework. Yet, it is often passed over in favor of a “quick-fix” in the form of a tech solution. Relatively small adjustments in how teams approach DevOps can make a huge difference, as any practitioner of nudge theory will tell you.

Here are six top tips to get DevOps delivering again.

Silo or Service Approach?

Consider switching to a horizontal software organization, sometimes known as a flat hierarchy, in which people are responsible for end-to-end ownership of the service they are tasked with. It is empowering because it gives them a complete view of what the service should be responsible for. In a vertical organization, the developers tend to become siloed and it can be hard to appreciate the bigger picture.

Adopt Microservices and Container-based Architectures

These technical advances have influenced how teams are built and how they operate. Their relative isolation forces teams to be organized independently. With that, comes flexible working and responsibility for the complete life cycle. View microservices and container-based architectures as opportunities for DevOps team members to have more ownership of deployments and results in faster release cycles.

Publish Matrices for Increased Visibility

There is a lot to be said for increasing transparency between teams and their members. Foster some healthy competition, share best practices or simply provide criteria for teams to match performance. This can be achieved with automated matrices that show software development and release agility, operational efficiency and quality of service. This kind of transparency is a motivator and will act as a catalyst to improve engineering.

Automation Leads to Motivation

Automation is vital for achieving scale and speed, as such, it is rightly seen as a DevOps must-have. It is also valuable because it frees up people’s time from routine activities and manual, repetitive, error-prone tasks. These manual tasks do not just burn precious work hours and reduce quality, they also grind down morale. Give developers interesting things to work on that are strategically important to the organization.

Immediate Feedback

In DevOps circles, people obsess about the importance of tightening customer feedback loops. But in an age where social networking is ubiquitous, it is not just customers who want immediate recognition more than delayed gratification. Employees are no different! Provide immediate feedback on code/ build/ test/ deployment /deviations from guidelines as they happen, so that corrective actions can be taken immediately.

Top-Down Commitment

DevOps requires C-suite commitment. This is especially true in the early stages of a DevOps implementation. Projects stall for various reasons. For instance, businesses can find it challenging to adapt organizational structures to fit the DevOps way of working. Technical hiccups occur too when technologies are new and its practitioners are learning the ropes. Active, unified support from management helps smooth the path to DevOps, deploying help and resources to ensure the project remains on track.

DevOps is one part technology, one part process and one part people. It is easy to take it for granted. Too often, businesses prioritize the tech and the processes and forget that what makes DevOps transformational. It is the bringing together of two (formerly) distinct groups, the development and operations teams. A nudge, a pat on the back or a common goal go a long way. These softer skills pack a bigger punch and deliver a better bang for the buck.

— Naveen Kumar

June 4, 2018
Coming Apart in the Age of Automation

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

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

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

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

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

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

What Does This Have to do with Automation and DevOps?

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

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

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

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

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

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

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

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

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

— Bob Reselman

May 31, 2018
Blockchain: A Threat to DevOps—and How Engineers Can Respond

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

Blockchain, Fat Protocols and a New Generation of Applications

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

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

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

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

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

How It Changes DevOps

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

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

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

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

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

Blockchain-Proofing DevOps

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

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

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

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

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

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

— Chris Tozzi

May 30, 2018
Using CALMS to Assess an Organization’s DevOps

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

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

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

Applying CALMS

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

Culture

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

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

Automation

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

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

Lean

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

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

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

Measurement

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

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

Sharing

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

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

The End Result

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

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

— B. Cameron Gain

May 25, 2018
Chef Embraces Microservices to Advance IT Automation

Chef at the ChefConf 2018 conference today unveiled a series of DevOps offerings, including a revamped version of Chef Automate that has been rewritten using the Go programing language to improve performance and scalability. Now based on a microservices architecture, Chef Automate 2.0 a new user interface based on a REST application programming interface (API) that also serves to enhance integration. There also are a variety of visibility and debugging tools built into the platform, including a streaming event feed, trend graphs and a query language.

Chef Automate

At the same time, Chef unveiled Chef Workstation, which enables members of a DevOps team to take advantage of IT automation capabilities on a local PC without having to load any agents.

Chef also updated its Habitat application release management software to include support for Kubernetes Operator for Habitat and the Open Service Broker originally developed by the Cloud Foundry Foundation, the ability to export to Azure Container Service (AKS), a Helm chart exporter for Kubernetes clusters and integration with operational analytics software from Splunk. Habitat also is now available in an on-premises edition as well as as a software-as-service (SaaS) application.

Finally, Chef updated InSpec, the company’s compliance automation tool. The latest version can now verify Amazon Web Services (AWS) and Microsoft Azure policies, while support for the Google Cloud Platform support is in beta. InSpec also now has built-in support for more than 30 new resources, including Cisco IOS network devices as agentless targets.

Chef is touting InSpec performance gains of 90 percent on Windows and 30 percent on Linux systems.

Julian Dunn, director of product marketing for Chef, said as more companies transition to emerging technologies such as containers and Kubernetes, the need to rely on IT automation frameworks increases. In fact, while container use is widespread, more than half (51 percent) of 347 application and operations professionals surveyed by Dimensional Research on behalf of Chef said they have fewer than 10 percent of their production applications deployed using containers. Dunn said that survey also finds that adoption of DevOps practices in general are still limited—just over half the respondents (53 percent) said they are using both infrastructure and app automation for DevOps.

However, 46 percent survey respondents said by 2020 they will have more than a quarter of their applications containerized, while 45 percent said at least a quarter of their application deployments will be based on microservices. That accelerated rate of transition will require IT organizations to rely more on IT automation frameworks to implement DevOps processes, Dunn noted.

Further complication matters, Dunn said organizations are trying to lift and shift existing applications into multiple public clouds while continuing to develop new applications faster than ever to drive various digital business transformation initiatives.

There’s no doubt that IT organizations are relying more on IT automation frameworks more than ever. The question is, Which one will they use? There are now more IT automation framework choices than ever. Chef is betting that a comprehensive approach based on a modern microservices architecture spanning both IT management and compliance ultimately will win the day.

— Mike Vizard

May 23, 2018
The DevOps Management Perception Gap

The DevOps momentum is fierce in the enterprise today, as executives and middle management recognize the transformative power that continuous delivery of software has for a business. The message that DevOps can lead directly to increased profitability for organizations has seeped into technology leadership consciousness and tech leaders are gung-ho to reap the rewards.

The problem is that their enthusiasm isn’t necessarily translating into a meaningful enough change in leadership patterns to really optimize the benefits of DevOps. The “2018 Global Developer Report” released by GitLabs recently offers some meaningful evidence of this. Study results hint at some Pollyanna-ish attitudes by managers that potentially could be leading to them resting on their leadership laurels.

The GitLab study showed that managers are overestimating their DevOps teams’ performance as compared to the developers who are on the ground getting the work done. While 81 percent of managers say DevOps saves time in the development process, only 65 percent of developers agreed with that statement. There was a similar disparity when it came to awareness of speed of delivery capabilities: Approximately 47 percent of managers said their organization deploys code on demand or multiple times a day while only 39 percent of developers said the same.

This gap could point to a potential disconnect growing within leadership that’s unable to adjust their management style to DevOps’ democratization of everyday development responsibilities. The study shows that almost a third of managers admit they don’t have visibility into what others are working on.

While individual teams do need to be given the autonomy to get work done with less red tape in the way, leaders still need to provide companywide direction and strategic supervision. In the end, teams need to come together to meet global business goals, and that’s where managers need to step in.

“What you need your leadership to do is apply systems thinking, and that’s a whole another subject we could get into, but I don’t think executives and leaders know how to really address the, ‘How do I optimize this as a whole?’” Carmen DeArdo, technology director for Nationwide Insurance, recently told DevOps.com. “You need to really focus on the strategy and make sure you’re removing barriers and allowing teams to innovate and improve your delivery capability.”

Unfortunately, the GitLabs study proves out DeArdo’s point, showing that leaders are missing their mark in this regard. The survey showed that “unclear direction” is the top challenge named by developers in getting their work done. It was cited by 67 percent of developers as their biggest impediment.

Meanwhile, managers may not be aware that they’re not providing proper direction. Managers are 35 percent more likely to say they set project expectations up front than developers are to say they receive such requirements right out of the gate. In fact, only half of developers agree that they receive ample expectations and requirements from the start.

— Ericka Chickowski

May 23, 2018
The Past, Present and Future of DevOps Infrastructure
Infrastructure automation enables organizations to set up operating frameworks that allow smooth functionality with enhanced usage, minimal scope for error and faster deployment of code. The process of infrastructure automation eases development and operations processes by introducing good deployment practices such as computerized testing and versioning.

The need for automation was realized when the demand for deploying error-free applications at a faster rate increased. Additionally, competition from similar businesses forced organizations to look for a way to bridge the gaps between development and operations to deploy applications that would serve their business needs.

The Challenge of Implementing DevOps Practice

The following challenges present a roadblock in bringing out the best results of DevOps practices:
1. The disparate work cultures of the development and operations teams.
2. Non-involvement of DBAs in release cycles.
3. Failure in deployment of error-free codes.
The Emergence of DevOps

The introduction of DevOps practices resolved a lot of problems in terms of increasing business operations efficiency. It created a common operating framework where disparate teams including development and operations teams can work together and deliver applications faster that will, in turn, result in effective business operations and an increase in ROI.

Adopting DevOps involves:
1. DevOps experts outlining of traceable metrics for creating a roadmap by visualizing the desired outcome.
2. Creating a pilot framework that will include the tools of both development and operations teams further integrating these existing tools with the DevOps experts’ robust ecosystem,
3. Analyzing, designing, constructing, automating and implementing the network based on the metrics and resources collated.
DevOps Tools:

The DevOps infrastructure automation process uses several tools that define and drive the success of the implementation process. Here is a short overview of some of the more well-known and widely used tools.
- Jenkins – A Java-based continuous integration (CI) tool contributes to the faster delivery of applications. Jenkins must be aligned with a version control system such as GitHub or SVN. Whenever the code repository receives a new code, a Jenkins server builds and tests the new code and informs the team about results and any changes. Over time, Jenkins has moved from being just a CI tool to being used as an orchestration tool that builds pipelines for application provisioning and deployment.
- Chef – A ruby-based configuration management tool, Chef includes cookbooks that code infrastructure in domain service language (DSL) in combination with a little bit of programming. Chef creates virtual machines and customizes them in accordance with the rules listed in the cookbooks. An agent residing on all the servers that need configuration extracts the cookbooks from the chef master and runs them on the server to get the desired results.
- Puppet – Also, a ruby-based configuration management tool, Puppet was developed with system administrators in mind. A configuration code is written using Puppet DSLs and is wrapped in modules. Puppet performs a similar function to Chef but, unlike Puppet, Chef is a developer-focused tool. It runs a puppet agent on all servers that require configuration and extracts the compiled module from the puppet server and installs required software packages as prescribed by the module.
- Ansible – An agentless configuration management and orchestration tool, Ansible can be used for cloud computing. Ansible has configuration modules called “Playbooks,” which are written in YAML format and are easy to compose in comparison with other configuration management tools.
- Docker – Docker, a process-level virtualization tool, creates isolated environments for applications known as containers. These containers can be transferred to any other system without making any application changes. Docker has evolved as the next step in virtualization. It is beginning to become a favorite of many DevOps practitioners and leading cloud experts.
The Future of DevOps Infrastructure Automation

A lot of organizations are beginning to benefit from the implementation of DevOps infrastructure automation. And with the pace at which the demand for DevOps services is increasing, infrastructure automation has a long way to go.

As per statistics, by bringing DevOps practices into the picture, organizations can benefit by deploying code up to 30X more frequently and reduce the deployment failure to less than 50 percent.

— Veritis
May 22, 2018