devopsy.kinsta.cloud

Category: Enterprise DevOps

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

January 13, 2020
Five IT Ops-tackles that Stifle Business Growth

I was recently asked about the top five IT obstacles that stifle business growth, and I want to help clear a path too often lined with fear, uncertainty and doubt. In the not-so-distant past, IT was all about the tools. Solutions were more straightforward, teams were less globally connected, and the ever-present data deluge was not changing our business landscape by the millisecond.

With this in mind, I have created a list of the five most common IT obstacles and will pinpoint the single tool you can implement to help alleviate these pain points.

IT Staff Lack Time to Learn New Technologies

This is not to slam our tech teams or leaders; this is just the byproduct of condensed customer schedules, tight purse strings and managing the MOOSE (maintenance and operations of the organization, systems and equipment). The demand on IT teams is high, and we don’t always have the opportunity or the resources to restructure operations for a new tool, as upgrading requires learning new APIs, UI/UX and deployment architectures.

Difficulty Supporting New Technologies Quickly

It is hard to keep pace with IT complexity and manage it properly. New services, applications and infrastructures are constantly being added and there are plenty of vendors out there that will get you locked into solving a single issue versus addressing your macro problems. While the benefits of upgrading are there, the difficulty lies in understanding the complexity of these systems and how to leverage them most effectively.

Lack of Support for Hybrid IT

Hybrid by definition adds complexity, and multi-cloud, on-prem and private/public clouds are only a few ways to make your hybrid dream a nightmare. No matter the combination, understanding different architectures and their components is a must. Additionally, we need to understand how we manage our own data as well as how our vendors are managing it.

IT Complexity

We need to know our machines and architectures well enough to focus limited resources on what impacts the business most. IT will always be complex—there’s always something new, and the amount of information to process is insurmountable and exhausting. Adding context to IT data can help you identify the root cause of overly complex systems. The most difficult task will be to understand the technology well enough to know what to do next.

Inability to Understand Business Impact in Order to Prioritize Tasks

Prioritization is by far the most important aspect of IT. There is a lot of noise, lack of visibility, lack of context, and—the squeakiest wheels of them all—legacy tools. Prioritizing means routing the right people to the right problem to get it solved quickly and elevating IT service visibility, health and risk into the business function.

Let’s Get Digital

IT pros can start to tackle these challenges through prioritization and then automation, or AIOps—the principal of AIOps being to add context to data, using machine processes to enrich the data and bring it to a business level. Understand what is important to the organization and think about the outcomes important to IT. To do this, you can create a realization plan to tackle the low-hanging fruit and create achievable milestones and outcomes. For example, look for opportunities and create a crawl-walk-run phased approach driven by business priorities. Each organization has different needs and different timelines—and this process can be applied to customers, too.

Next, take into account how your team does work and focus on automation as a principle within how you do work. One of the biggest impediments to digital transformation is culture. Remove manual processes, capture tribal knowledge and figure out how to repeat this approach in a consistent way. Additionally, absorb feedback and learn from it. This will drive acceleration when done right, and we all know that better digital experiences boost enterprise value.

Finally, automation is useless if your data is flawed, and accuracy is a key fault for legacy configuration management database systems. Data must be accurate for effective machine-enabled automation. Leverage the tech you have to build an interconnected ecosystem that is fully integrated and automated—and that avoids tool sprawl. Have an open mind to consider new approaches and be brave enough to shed the legacy mindset. Additionally, take into consideration your partners and vendors, and how that team collaborates, to determine your strategy.

The Light at the End of the Tunnel

The path for today’s CIO can be unclear. But you can take bite- (or “byte-”) sized steps to put machines to work and leverage processes that deliver on AIOps. By understanding business outcomes, prioritizing automation as a principle and leveraging trustworthy internal and external relationships, you will have more time in the day for more important tasks. I measure outcomes based on customer experiences, and I ensure great customer experiences by running a great system. While your mileage may vary, moving forward is the most important part.

— Erik Rudin

January 13, 2020
Is COBOL Here to Stay? Five Signs IT is Ready to Modernize

With increased demands and challenges around compliance and regulations, plus growing expectations for IT to provide more value-added services, companies are looking for more flexible and collaborative options. Interestingly though, while some IT departments have updated legacy systems, COBOL code has continued to be a mainstay. In fact, COBOL just turned 60 and many are saying it’s here for the long haul.

There are a lot of reasons that make it challenging—or for some, unnecessary—to move away from the language, but there are also several clear signs companies and IT departments should know that indicate it’s time to make a change.

Here are five signs IT leaders should pull the trigger on modernizing their legacy environments.

You’re Constantly Worried About the Risk of Losing COBOL Expertise from Your Team

COBOL has more production lines of code than any other language in existence, with over 220 billion lines of COBOL today—or around 80% of the world’s actively used code. One of the problems is that many that are well-versed in COBOL language are also nearing retirement, and the amount of COBOL programmers entering the market is much lower than it was 10 years ago.

Author Glenn Fleishman put it best in his article on the subject stating “the language never died, though its early practitioners have faded away, and the generation of programmers who built systems towards the end of the predominant mainframe era in the 1970s and 1980s are largely near or past retirement age. It’s a slow-moving crisis with no crackling deadline, like Y2K, to focus the minds of Chief Information Officers.”

Pressure from Business Leaders to Take Advantage of More Agile IT Methods

Whether it’s cloud, DevOps or microservices, businesses want faster and more frequent IT delivery of new services to customers. In order to drive these results, embracing more agile methods of IT and developing a strategy that can support rapid application delivery is key. Moving to the cloud, integrating with Java or shifting to Linux requires open-based models that can handle legacy COBOL applications.

You’re Quickly Losing Your Competitive Edge Because of the Reliance on Dated Technologies

Direct and even indirect competitors are encroaching more and more in the industry and in new deals, and you feel as if your company’s position in the market is slowly declining. This may be a product of competitors’ willingness to open source systems that promote the business agility needed to react far more quickly to changing market dynamics and customer demands.

If they are modernizing their IT and investing in new technologies quicker than you are, it’s likely they’ll catch up to or surpass you quickly.

Your Confidence in Your Current IT Environment Is Extremely Low

No matter the modernization strategy you pursue, you should ultimately feel confident and peace of mind when it comes to your environment today and as you look to the future. Without flexibility, collaboration and a tailored approach however, the business will likely suffer and may be the reason for the growing insecurities.

For instance, if you’re interested in programming COBOL in some areas, but currently operate in a significantly pure native Java environment, a flexible and manageable solution is key. If you want to generate Java as the compiled object, the result will be inflexible static Java objects, rather than something flexible and extensible — and will require access to the Java source. That source is not nearly as maintainable as the source generated in the COBOL to Java conversion, but can be leveraged in Java-operating environments, and is much more flexible than other alternatives.

You’re Experiencing Vendor Lock-In

You’re wedded to an established tech company or consultants on-hand that seem like safe bets, but instead have caused you to miss the mark in being flexible and future-proof–not to mention are likely far over your budget to maintain. While transitioning to a new partner may seem daunting, conducting an assessment of your operational, infrastructure and application environment can provide a more comprehensive picture of the strategy that is right for the business, help manage the process more efficiently and ultimately cut unnecessary costs well before an exact migration or conversion path is decided on.

Although many organizations have run COBOL without substantial updates and issues for decades, the ability to solely rely on the dated technology is quickly giving way to a growing need for additional languages and more agile systems. If IT leaders are experiencing one or more of these issues now, waiting any longer to address them can result in much bigger problems in the future and considering a modernization strategy may be the better path to success.

— Cameron Jenkins

January 10, 2020
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

January 10, 2020
A Developer’s Task: Minimizing Challenges Created by Fragmentation

Over the past decade, there has been a wellspring of apps, services and platforms to help developers build custom solutions for businesses. Some are great, some not so much. Regardless of quality, the quantity of options and each one’s varying level of sophistication has made it difficult for developers to separate the wheat from the chaff.

A recent survey from IDC supports this notion. It contends that the current landscape of software development languages and frameworks is highly fragmented. Having too many options—as opposed to a single, unified environment—leads to holes and disconnects in the development process, not to mention the potential for significant complications in the long-term support of today’s apps.

Here are some ways developers can navigate the challenges created by this high level of fragmentation.

Don’t Be Afraid of Low-Code (or No-Code) Solutions

The IDC survey found that less than half of developers—44%—have used low-code development tools professionally at one point or another. As one would surmise, low-code programming brings with it a host of advantages, such as easy-to-use and intuitive interfaces, and the ability to deliver applications faster.

Some low-code platforms also enable developers to build applications that can be used on any device while also reducing dependency on outsourced IT. A built-in script builder can allow even relatively inexperienced developers to turn complex business logic into functional workflows—such as automating a repetitive task—within a matter of minutes. Even after apps are launched, workflows can be updated and customized to fit specific business needs nearly instantly.

Achieve Scale with Serverless Applications

When building on a serverless platform, developers prevent infrastructure maintenance from inhibiting applications from scaling globally. This also allows developers to build mobile apps without managing the backend infrastructure. Cloud computing using public clouds typically involves renting virtualized servers across the technology stack. But when looking to scale, the onus is on developers to deal with the operating system and database while also managing necessary updates. This can lead to a work-intensive process on the app infrastructure level.

A serverless infrastructure, on the other hand, abstracts databases and file servers, shifting focus to the app logic level. This allows developers to build and manage microservice-based apps that integrate with other services, making it easy to scale applications.

Make Things Easy on Your Team

According to the IDC survey, just 20% of developers claim they are “extremely familiar” with containers and microservices. With such expertise hard to find, using flexible tools that allow teams to quickly deploy code in scalable, compartmentalized components is vital.

Organizations should aim to help their developers focus more on designing top-class user experiences of serverless applications, rather than spending (or wasting) time and resources on setting up and maintaining components on the server side. This gives developers the ability to focus on doing what they love—developing—as opposed to other tedious and mundane activities such as manually managing servers and storage solutions, or tweaking the underlying infrastructure of their microservices.

Of course, making things easier for developers means deploying a powerful tool built on a stable foundation that can offer SDKs and APIs for both mobile and web apps, the ability to test early and often in a sandbox environment and analytics that monitor and report performance in real-time.

Developers know just how challenging their jobs can be, and the fragmentation that can occur due to the vast number of options on the market can make it even worse. There is nothing wrong with using multiple solutions, of course, but having a sturdy and unified underlying infrastructure goes a long way toward avoiding unnecessary headaches.

Finally, organizations should look to those who know best when deciding which company-wide tools to implement: the developers themselves. As the IDC study states, developers should be viewed as key stakeholders in IT purchasing within any organization moving to the cloud accompanied by an internal digital transformation.

— Raju Vegesna

January 9, 2020
API Security in DevOps: Are We Too Comfortable?

Postman performed its annual survey of developers, and as this survey and many other surveys have shown, developers are generally comfortable with the level of API security that their organization has implemented. This has been a consistent trend, with most developers being comfortable that they are protected.

The problem is most organizations also put API security and management in the hands of developers.

Knowing the rate of change going on in Agile/DevOps shops, and knowing the complexity of environment, I think this mentality is akin to the pre-WW2 French belief in the Maginot Line.

While API security is certainly a necessity, it is not managed in a vacuum. You really are only as secure as your weakest link, and there are a lot of links in an API-focused environment. User credentials, tokens, SSL, requesting apps and their authentication, (still) code injection concerns…The list goes on and on.

I’m never comfortable with the level of API security currently implemented in DevOps environments. And I think it’s dangerous for you to be. It only takes one bad code iteration for one of the client instances to be vulnerable. That vulnerability exposes every API the client in question has access to, no matter what is being used as access control.

In the end, APIs must trust someone, or they’re useless. And that someone is most often a server app running on an instance that your users connect to. That app most often has its own credentials. How are they stored? How are they protected? What code changes could impact that instance’s security?

API gateways and management tools, when properly configured, are a big help here, but they are not a panacea. Since incoming connections must be trusted at some point, and outgoing connections must be assumed clean at some point, when one of those two things is a wrong assumption, what do you have in place?

Here’s the scenario: User A has rights to call the ShowMeCriticalData API. This API is called from a server app running on instance B. The server app authenticates user A, then calls the API for him–either with his credentials (best case) or its own (bad for tracking problems). If instance B receives an update that makes it vulnerable to compromise, user credentials are still needed to call ShowMeCriticalData, which is relatively secure, as long as User A is protecting their credentials adequately. However, if the app running on instance B is proxying requests and using its own credentials, Instance B becomes a weak point and attackers could use the vulnerability to call APIs without authenticating users. Worse, if User A is careless with their authentication info, there is little an organization can do to stop at least some misuse.

API logging and review can be put in place to notice odd behavior by username, and offer early warning that a user has been compromised. But will only catch most issues.

Of course, there are smart people working on the whole array of API security threats from cross site scripting to authentication spoofing even into TLS weaknesses. But that work is only useful if we all remember that our security could be better. With knowledge that there are weaknesses, we can look for things to mitigate the risk. As you all know, if you have public APIs the risk will never be eliminated–the purpose of a public API is for people to use it, and that exposes it to hackers that seem to be more ingenious by the week–but minimizing the risk is worth the effort.

Being secure in your current situation means you’re not focused on making it better. With API security, particularly in the type of dynamic environment DevOps creates, this is a dangerous road to be on. Assume there is a fatal flaw, and work to reduce vulnerabilities at each access point into the overall system.

This also goes for APIs you don’t own. We rate limited an API that called out to Google Places to match up with our plan/budget for the project. Our app was never going to come anywhere near Google’s caps on usage, but should a portion of our infrastructure be compromised, we could potentially end up with a massive bill from Google because we called the API a zillion times in a month. Likely? Not really. Possible? Not after a few lines of rate-limiting code.

You all have made some astounding apps. Make sure they are astoundingly protected. Because both business and users are counting on it.

— Don Macvittie

January 8, 2020
Leadership Role in Adding Test Automation to Existing Environments

Leadership is the foundation for all agility. I’ve written elsewhere extensively on a model that works well for the new environment in which we find ourselves: the need for tens or hundreds of very smart people, doing things that have never been done before with new tools, working with people they may not be familiar with. These creative, expert people make dozens of decisions a day that few others see in real-time, turning ideas into code that must run flawlessly and execute complex business processes. Quite a leadership challenge.

The leadership model I’ve articulated is simple. Leaders at all levels should focus on rigor (good decisions based on options and data), alignment (everyone rowing in same direction) and efficiency (respecting everyone’s valuable time). Getting the right people, with the right skills and the right kinds of interactions, is more valuable than having the right process and tools.

For software agility, we know reducing the friction between development and productive use is a powerful leverage point. This general area we now call DevOps. Coming from the application space as I do, my primary focus has been on test automation. How can we at very low cost continually ensure that our evolving software is ready to be deployed to production (or production staging, if we are doing periodic bundled software deploys)?

I’ve recently watched a team introduce test automation into an existing application environment. Great leadership was demonstrated throughout by multiple team members. Let’s examine the steps taken and point out the leadership that made it happen.

Set the Target

Team and organizational leaders laid out a clear vision of the business benefits and their support for the initiative. This was the culmination of several months of learning, communication and cost/benefit analysis. Leaders gained alignment based on rigorous analysis.

Ensure Adequate Leadership and Technical Skills Are in Place

In the run up to the inception of the work, leaders hired an experienced testing leader, who in turn hired a couple engineers to do the work. Because the environment was a common one in the industry (Salesforce was a big part of it), the leaders sought the best expertise they could find, and wound up engaging an external specialist firm to get them going. People over process.

Define the Technical Architecture

The new team leveraged the knowledge of the consultants and some of their engineering partners to examine options and select an approach. They shared the options and analysis with their team and leaders and gained consensus and understanding. In the process the approach was fine-tuned. The team demonstrated rigor and efficiency and gained alignment. One key of their success was the “towering technical expertise,” a lean product development term, brought by the consultants.

Deliver Incrementally

For this item, I will describe the solution chosen, since the specifics will be of interest to this audience. The vision was to train the product owner/systems analysts to write acceptance criteria for each user story (which was the unit of development here) in the stylized language Gherkin. As the development was done during a sprint period, the test team would take the Gherkin and write automated tests for the test tool Cucumber, which would drive execution in Selenium. The execution would be automatically connected to the deployment of new code using Jenkins.

The team wanted to avoid disrupting the existing flow until the risk was reduced based on proven results. Accordingly, they began by building automation for existing software, proving that the vision worked in practice, and gradually completed the regression suite and started to catch up to work in process that hadn’t been released. Excellent leadership for agility was demonstrated again, driving rigor through proof of the concept and laying the groundwork to get the rest of the team aligned.

Get the Rest of the Team to Change

Once the test team caught up to being able to do in-sprint automation, they needed to tackle the training and acceptance of a new way of writing acceptance tests (in Gherkin). The great results they demonstrated helped influence the product owners and systems analysts to give it a try.

Continuously Improve

As the creative period of designing the test automation approach and getting into production came to an end, a new period of measurement and continuous improvement began. Here we have another foundational element of leadership for agility: understanding where we have repeatable flows where process really is the key, and where we have a creative endeavor in which the focus on people and interactions must rule. In a sense, the team transitioned from a product development effort to a manufacturing-like flow, and they accordingly changed their approach.

Conclusion

Sometimes we make the mistake of thinking that getting to efficient DevOps is all about tools and processes. My experience is that to the contrary, leadership is the key. As the first value of the 2001 Manifesto for Agile Software Development states, “People and interactions over process and tools.”

— Michael K. Levine

January 3, 2020
Best of 2019: Implementing Message Queue in Kubernetes

As we close out 2019, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the fourth in our weeklong series of the Best of 2019.

The adoption of Kubernetes as enterprises’ tool of choice is increasing very rapidly. Consequently, the architectural consideration and operational requirements to support production environments have gained increasing attention. A major challenge to consider when planning a scalable microservices architecture (MSA) that is orchestrated by Kubernetes is how to manage the heavy traffic of messages in the system.

After migrating from the monolith architecture to a microservices architecture or setting up a new MSA, each microservice holds its data model and is disengaged from the rest of the system. When scaling, it is observed that a project can grow to hundreds or more microservices, and the messaging traffic can become enormous in systems that generate millions of messages a day. Hence, there is a need for a new robust communication between the microservices to be established.

Using Point-To-Point connectivity such as REST to solve the communication gap in Kubernetes can end up creating a complicated structure between the services. A consequence of this is the need for comprehensive maintenance by the development team each time service requirements are changed. This is where a messaging queue system comes in handy to take care of the messaging challenge in MSA and Kubernetes. Each service communicates with one focal point (message broker queue) in its own language and the message queue system is in charge to deliver the messages to the services which are waiting for it.

To build a well-managed messaging solution for Kubernetes, the message queue system should be native to Kubernetes, support the relevant messaging patterns, robust and secured. Being native to Kubernetes is a critical parameter to achieving a healthy system in Kubernetes. It includes a simple and fast deployment to Kubernetes (and not outside of the Kubernetes cluster), low DevOps maintenance and well connected to Kubernetes ecosystem for logging, monitoring and tracking.

Hybrid Cloud

A hybrid cloud solution enables enterprises to make use of both on-premises and public cloud services. An advantage of a hybrid cloud is the flexibility it offers–allowing workloads to alternate between the two environments when capacity and costs change, for example. Sensitive workloads and data can be hosted in the private cloud or on-prem while less critical workloads are hosted in a public cloud. Regulatory requirements for data handling and storage can be provided in the private cloud. A commercial advantage of public cloud services is cost, both in terms of CapEx and OpEx, as the scalability it provides allows an organization to pay only for the resources it uses. Deploying message queue in Kubernetes provides the technology that allows the hybrid clouds to smoothly and transparently connect and interact.

Use Cases

There are many use cases for message queues. The message queue needs to support diversified messaging patterns, enabling flexibility in creating different use cases.

Here are some of the common use cases a messaging queue system should support in Kubernetes.

Multi-stage Pipeline

The synchronous pattern is used when we need to process the messages in a coordinated way in a workflow. Pipeline use case allows processing messages in a sequence between services. Each service can be considered as a stage, and the message passed between all the stages in a sequence. In some cases where the message is lost or cannot be processed (for any reason), the dead-letter queue mechanism takes the message and process it in a pre-defined way.

Job/Task Distributed Queue

The A-synchronic pattern is used by some producers to many consumers when we need to distribute tasks/jobs between workers. In this use case, there is no need to coordinate between tasks. Each service is pulling messages from the queue to process it. The sequence of processing the messages is not important as each worker takes the task from the queue and process it in his own time.

Figure 1: Tasks/Jobs Distributed Queue.

Stream

The A-synchronic pattern is used when we need to stream data from many external sources (big data, IoT) and process it in a dedicated service such as database, pipeline, machine learning, storage, etc. This case typically aggregates many producers to a small number of consumers. The order of messages is not important, but the delivery guarantee is important.

Pub/Sub Real-Time

The A-synchronic pattern is suitable for cases of a small number of producers sending real-time data to many consumers. A service acting as a publisher sends a message to a channel where a set of services subscribe to that channel and get the messages.

Application Decoupling

Connectivity between services such as edge, API, databases and storage act like a router, and message order is not important; timeout and sync between producers and consumers are important.

Ease of Use

One key feature of the microservices architecture is its ease of use. Deploying it saves your organization time and money by unifying development and operations workflows. The message queue system needs to be easy to use as well. Its ease of use and DevOps’ friendliness should minimize the need for dedicated experts and, at the same time, accelerate development and production cycles. While considering this, it’s important to ensure support in high volume messaging with low latency, efficient memory usage and fundamental messaging patterns (real-time pub/sub, request/reply and queue) are not compromised.

Gradual Migration to Kubernetes

When IT professionals evaluate the significant advantages of using the Kubernetes environment, they cannot ignore the operational requirements necessary to maintain the revenue-generating monolith infrastructure. Legacy systems also contain the processes and data related to the on-going business and are crucial for the service contingency.

To support a gradual migration that keeps the business operation, the Kubernetes message queue must enable connectivity between the old and new environments. A bridge is required to connect the legacy side to IBM MQ, TIBCO, MSMQ or Kafka (just to mention a few popular enterprise solutions), to the Kubernetes message queue that allows a seamless bi-directional transposing messages between the services in the legacy monolith environment and the microservices-based deployment in the Kubernetes environment.

The bridge installed in the legacy environment is “listening” to the MQ on behalf of the relevant services in the Kubernetes environment, ensuring the designated messages are transferred from the monolith to Kubernetes and vice versa. This bridging capability enables gradual migration by implementing a step-by-step replacement of components from the old environment or the creation of new services that can still connect with the legacy resources.

Figure 2: An example of gradual migration from MSMQ on the on-premises environment to AKS.

To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

— Lior Nabat

December 31, 2019
Best of 2019: The Time Has Come for an Engineering Approach to DevOps

As we close out 2019, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the third in our weeklong series of the Best of 2019.

Do you want to know how to do DevOps? Are you doing DevOps but not satisfied with the results you are getting? DevOps is complex. It does not come with a prescription, installation guide, user’s manual or maintenance manual. It doesn’t even have a standard definition. How can anyone expect to get good results with DevOps without clear and definitive guidance? There are plenty of books that describe different aspects of DevOps and customer user stories, but up until now there has not been a book that frames DevOps as an engineering problem with a step-by-step engineering solution and a clear list of recommended engineering practices to guide implementers.

My book, Engineering DevOps: From Chaos to Continuous Improvement … and Beyond, provides a step-by-step engineering prescription that can be followed by leaders and practitioners to understand, assess, define, implement, operationalize and evolve DevOps for their organization. It provides a unique collection of engineering practices and solutions for DevOps. By confining the scope of the content of the book to the level of engineering practices, the content is applicable to the widest possible range of implementations.

This book was born out of my desire to help others to do DevOps, combined with a burning personal frustration. The frustration comes from hearing leaders and practitioners say, “We think we are doing DevOps, but we are not getting the business results we had expected.”

There are many documented references, courses and other sources of information that explain a multitude of different aspects of DevOps, but there is not a comprehensive step-by-step prescriptive guide that details how to engineer a DevOps solution for any organization given any starting point.

Engineering DevOps takes a strategic approach, applies engineering implementation discipline and focuses operational expertise to define and accomplish specific goals for each leg of your DevOps journey. This book guides the reader through a journey from defining an engineering strategy for DevOps to implementing The Three Ways of DevOps maturity using engineering practices: The First Way (called “Continuous Flow”) to The Second Way (called “Continuous Feedback”) and finally The Third Way (called “Continuous Improvement”). This book is deliberately intended to be a guide that will continue to be relevant over time as your specific DevOps, and DevOps more generally, evolves.

Structure of this book

This book is organized as an engineering reference guide presented in five parts as follows:

Part I: What Is Engineering DevOps and Why Is It Important? is organized into three chapters. Chapter one, “What is Engineering DevOps?,” explains engineering concepts and terms used in this book that have proven to work with many clients I have encountered during my consulting experiences. My depiction of a DevOps Engineering Blueprint is presented for as a useful, practical “big-picture” reference for discussing engineering the major parts of DevOps. Chapter two, “Nine Pillars of DevOps,” describes a classification of DevOps practices that I have found to be useful characterization of DevOps engineering practices readily applied when engineering DevOps implementations. Chapter three, “Why Is Engineering DevOps Important?,” explains the benefits of taking an engineering approach to engineering DevOps.

Part II: Engineering People, Processes and Technologies for DevOps provides a comprehensive explanation of recommended engineering practices for the higher levels of the DevOps Engineering Blueprint. DevOps transformations are not normally understood or applied using strict engineering principles. Engineering practices are presented in nine chapters. “How Should DevOps Be Engineered?” includes a discussion of DevOps Engineering Maturity Levels for each of the Three Dimensions (People, Process, and Technology), Twenty-Seven DevOps Engineering Critical Success Factors and Lean DevOps Value-Stream Pipeline Engineering.

I describe recommended engineering practices for the top layers of the DevOps Engineering Blueprint in the next chapters, which include “Value-Stream Management (VSM),” “Application Release Automation (ARA),” “Version Management,” “Continuous Security (a.k.a. DevSecOps),” “Service Catalog,” “Governance,” “Site Reliability Engineering (SRE),” “Disaster Mitigation” and “Recovery.”

Part III: Engineering Applications, Pipelines, and Infrastructures Engineered for DevOps provides a comprehensive explanation of recommended engineering practices for the lower levels of the DevOps Engineering Blueprint, presented in six chapters as follows: “DevOps Applications Engineering,” “CI/CD Pipelines Engineering,” “Elastic Infrastructure Engineering,” “Continuous Test Engineering,” “Continuous Monitoring Engineering” and “Continuous Delivery and Deployment Engineering.”

Part IV: DevOps Seven-Step Transformation Engineering Blueprint provides a description and tools for my approach to realize and evolve DevOps. The seven steps are Visioning, Alignment, Assessment, Solution Engineering, Realization, Operationalize and Expansion. By using these tools, DevOps leaders and practitioners can create, implement, operate and expand their DevOps across the organization. The chapter goes further to explain how to evolve DevOps from a successful First Way DevOps (Continuous Flow) toward realizing more advanced Second Way (Continuous Feedback) and Third Way (Continuous Improvement) DevOps implementations. This part includes a discussion of “Beyond Continuous Improvement”—a look at emerging technologies shaping DevOps in the future, and how you can prepare your DevOps and yourself for the future. This part includes a discussion of how to set up an effective DevOps engineering training program that supports continuous learning of DevOps engineering skills needed to maintain and enhance DevOps.

Part V: Appendices, Continuous Learning, and References includes materials and sources I have found most useful for engineering DevOps.

To get a copy of my book “Engineering DevOps: From Chaos to Continuous Improvement … and Beyond,” or start reading for free, click here.

— Marc Hornbeek

December 30, 2019
Best of 2019: Critical Skills Developers Need to Avoid Getting Left Behind

As we close out 2019, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the second in our weeklong series of the Best of 2019.

Burnout is a recurring theme at DevOpsDays events around the world. The modern developer faces constantly and rapidly-evolving challenges: the agile movement reducing the development lifespan, the DevOps movement shifting production operational responsibilities into development processes and the complexity of cloud offering new architectures from SaaS through to FaaS, as well as microservices.

As these shifts occur, often ignored are the operational skills needed to support an application running in production. Developers expect to support production and be on call 24/7, but are IT leaders giving them the necessary tools and training? More and more, we need developers to be prepared and able to seamlessly oscillate between focused specialist and broad generalist. This article highlights a few key areas where software engineers need to bolster their skill sets to remain agile and effective in building applications.

DevOps and SRE Assume Broader Skills

Non-developers may interpret agile computing as developers creating a world where they get to code rather than document, follow process or deliver to plan. In reality, agile took the lengthy cycle of waterfall releases and replaced it with the frenetic continuous delivery of valuable software. DevOps was born from the need to deliver application updates rapidly and regularly.

The monitor phase of the DevOps infinite loop originally focused on ensuring application problem detection and diagnosis was possible. Moving from detection to prevention, DevOps practitioners had to shift their testing and quality processes. Developers were asked to code the application, while also creating the testing systems to validate their code and building the production executables. Progress here led to additional responsibilities. As development moved to agile and DevOps, infrastructure transformed into software defined infrastructure (SDI).

The separation of the operating system from the server hardware through virtual machines started the journey to SDI. Application containers removed the OS requirement and added cross-server mobility. Kubernetes and Docker Swarm allowed developers to encode application requirements in the recursively titled YAML. After containers, microservices is a further refinement that isolates an action into a separate piece of code—which is well suited for workload-based pricing of cloud environments. SDI’s capabilities bring us to where infrastructure definitions require a software development lifecycle (SDLC) of their own.

The outcome of all this is a massive increase in complexity that developers must consider as they code components of an application. It requires additional considerations of the infrastructure and business environment the application will run in. Developers can define the best YAML definition of needs for their new application, but does not mean the production infrastructure will be able to provide a matching environment.

Skills Developers Must Enhance

Here are some key areas where developers would benefit from honing their skills in order to stay relevant amid growing complexities mentioned above.

Networking

The single purpose of computer networking is to move data from the memory of one computer into the memory of a different computer. With TCP/IP protocols as the default network stack, the flexibility needed to survive a nuclear attack comes with a lot of variability in configuration. At the basic level, network components must be configured to identify how many bits of an address to use when searching for another network entity via Classless Inter Domain Routing (CIDR).

Software engineers need networking skills to understand how their software definitions may conflict with the eventual production network infrastructure. For instance, network definitions in the YAML descriptors for Kubernetes/Docker are generally set with a /nn configuration (e.g. /16). Conflicts arise when you overlap the pod addresses with physical server addresses or have a mismatch between development pods and production pods. If your pods-per-node count differs between pre-prod and prod environments, it is possible the CIDR settings will differ as well—as a colleague regrettably learned when using /8 rather than /16, leading to the largest production outage in their career.

In addition to these basics of network addressing, there are concepts such as micro-segmentation needing definitions of performance and connection requirements that span across containers, virtual machines and bare metal servers.

Security and Segmentation

Historically, applications have relied on production infrastructures with their firewalls and DMZs for protection from the outside world. That castle moat approach is insufficient for today’s threat landscape where applications live everywhere. Not only do enterprises need to protect against outside connections and attacks, they also need to prevent accidental connections from production applications to development, QA and testing environments. Crossing the streams can cause exposure of production data in test environments and, even worse, corruption of production data.

Ensuring that application components only communicate to specific services in specific environments is addressed with micro-segmentation and its ability to manage and monitor secure code-to-code communication. Control with this detail comes with its own challenges as incorrect or insufficient definitions could leave a production application unable to communicate with needed API’s or microservices. Making diagnosis in micro-segmented environments harder is the possibility that traffic for other transactions or applications may be successfully crossing the same environment. This is when you may hear the classic “it is working fine in test” response.

Micro-segmentation offers significant security benefits yet requires developers to clearly identify the required connections and components of any communication. The best time to note this is while coding, making this an important skill for the modern developer.

Dev and Ops Synchronicity

The synchronous arrival of DevOps and SDI provides a mutual opportunity for developer and operations teams. While developers need to learn production on-call skills and operations teams need to learn SDLC skills, both teams also need to remain current in security concepts. Some organizations tackle DevOps by creating merged teams, though members may continue to stay in their lane. Whether merging teams, or maintaining separation, it is beneficial to hold brown bag sessions to share information and help educate each other. Ask your operations peers to talk about their three most common production issues and the three most popular tools they use.

An important aspect of the application on-call generalist is having the right tool supporting them to effectively diagnose production outages and slowdowns. Whether developed as an in-house solution (with incumbent technical debt) or selected as a product, you will need something that can see from end-to-end and allow the code-centric software engineer to drill into databases, storage, networks and code components from an application point of view without having to learn siloed management and monitoring tools for each aspect of infrastructure.

While individuals come into a DevOps transformation with I-shaped specialists, they must leave as T-shaped engineers, thus enhancing their value to current employers and helping their career.

— Marco Coulter

December 27, 2019