devopsy.kinsta.cloud

Category: Enterprise DevOps

Why DevOps Implementation is Often Unsuccessful – and How to Fix It
Much like “blockchain” and “big data,” the term “DevOps” is another buzzword currently being thrown around the IT departments of large organizations.

Many have identified the need for faster software development life cycles; a more precise process closely aligned with business objectives, allowing for clearer workflow and collaboration between the development and operations teams. DevOps is essentially agile, all grown up and ready to take on the constantly innovating and rapidly deploying needs of the modern business.

For security professionals, it’s a fantastic initiative: We can inject security into the process far earlier, reducing the cost of fixing bugs and avoiding potential catastrophe down the track.

The problem is, few companies are truly successful in their DevOps implementation. Without the right support, nurturing and understanding across the business, it can quickly become a white elephant, you know, one of those “don’t mention the war” projects.

So, what’s the problem? There are a few ways to approach DevOps that I believe will make for much smoother sailing. An effective program goes beyond a few fancy new tools, titles and team meetings. It’s not always going to be easy but taking the time to fix a broken strategy (or implement it the right way from start) is going to be far less painful in the long run. Ultimately, it’s going to result in higher quality and more secure software.

Let’s break it down.

Let Go of the Agile Apron Strings

There is somewhat of a misconception that an organization must choose between agile or DevOps, setting down one path or the other, never to look back.

The thing is, the development process works best when both are being considered and implemented as one. DevOps is not a reinvention of agile development; rather, it is an extension of it. The wheels tend to fall off when there is an expectation the process will be exactly agile, or completely different from agile.

Agile supports the principle of cross-functional teams, bringing designers, testers and developers together from the beginning and committing to open communication lines throughout a project. Its aim is to stop siloed delivery and reduce double-handling, both of which are benefits of the DevOps process as well. However, DevOps goes a step further, introducing systems, security and operations into the mix to offer a robust, end-to-end skillset that had the ultimate goal of full, functional software delivery to the customer.

During the inevitable pain-points of moving to a more DevOps-centric process, the risk of siloed development can crop up again. You can often have the original agile team working together, with the security and operations additions still finding their way in the machine. No one is quite sure how to include them, what they should be doing and their overall objectives.

DevOps does not work without clearly defined objectives, cross-functional onboarding and direct communication with all parties. There will be an adjustment period requiring careful change management but getting everyone on the same page with the enhancements DevOps functionality will bring is half the battle.

Increasingly, DevOps is placing emphasis on security best practice as part of the process as well, demystifying that step and bridging the gap between the security team and everyone else. As I have said before, we still have a long way to go in empowering developers to code securely from the start, but the successful implementation of DevOps methodologies is an excellent foundation on which security skills can be built within the development team.

Automation Isn’t Everything (and It’s Not the Most Secure)

Another feature of DevOps methodology is, to a certain extent, the automation of the software development process. Continuous integration and continuous delivery (CI/CD) principles are the cornerstones of this concept, and as you can likely guess, very reliant on tools.

Tools are awesome. They can bring unprecedented speed to the software delivery process, managing the code repository, testing, maintenance and storage elements with relatively seamless ease.

However, while robots might take all our jobs and imprison us someday, they are definitely not there yet. Heavy reliance on tools and automation leaves a window wide open for errors. Scans and tests may not pick up everything, code may go unchecked and that presents enormous quality—not to mention security—issues down the track. An attacker only needs one back door to exploit to steal data, and forgoing the human element in quality and security control can have disastrous consequences.

The happy medium is to ensure you have a balance of people and tools. Tools should serve as the assistants to a team you trust to deliver on project goals. You should:
- Allocate enough time for people to become familiar with the chosen DevOps toolchain.
- Focus on effective collaboration (and how the tools can support that).
- Address any gaps in the process, whether they are skill/knowledge or tool-based.
In short, don’t just tool up and hope for the best.

DevOps Isn’t a Buzzword, It’s a Culture – Are you Growing Yours?

Change management is tough at the best of times. Fear of the unknown can stop even the most brilliant team members from growing their skills and expanding their horizons.

You see, merely saying “let’s do DevOps” and making the operations team move desks isn’t going to magically implement a successful process. Many will be confused, and long-serving members of the team will be left feeling disgruntled. Communication of expectations is crucial, as is walking the walk. DevOps represents a cultural movement just as much as a development methodology, and a team should live and breathe a cross-functional, collaborative mindset.

What does a great DevOps culture look like?
- Individuals are empowered to lend their expertise to a process, not just leaders.
- Open, honest and respectful communication between teams.
- Each person takes responsibility for the overall objective of building quality and security into the development process.
- Everyone is on the same page with the definition of DevOps in the business, the roadmap and how/what/why of each person’s role.
For years I have emphasized the importance of building positive security cultures in development teams, and DevOps is no different.

The right tools, knowledge and support are imperative to achieving security best practice, seeing a downturn in discovered vulnerabilities and opening the team’s eyes to the importance of protecting our data. With DevOps, you must lay the cultural groundwork for positive change: Ensure everyone understands their role, value and expectations, the overall project goals and steps in the process.

Have you mastered that? Great. Now, let’s shift the needle, dial up the security aspect and make DevSecOps the ultimate plan for software excellence.

— Pieter Danhieux
August 15, 2019
How to Transition to Become a DevOps Engineer
You’ve either heard the buzzword or you’ve seen the extensive list of rewarding aspects that come with being a DevOps engineer. Whatever the reason you’re here, this guide should help with taking the right steps toward becoming a DevOps engineer, whether this is your first job after graduating or an opportunity to reskill leveraging your prior industry experience.

Immerse Yourself

Learn the fundamentals, practices and methodologies. Understand the why behind DevOps before jumping into the tools. I believe the key goal of any DevOps engineer is to increase speed and maintain or improve quality across the entire software development life cycle, in order to provide maximum business value. Read articles, watch some YouTube videos and go to one of your local Meetup groups or conferences–it’s useful to become a part of the welcoming DevOps community where you’ll learn from the mistakes and successes of those that have been here before you.

Your Background

There are likely two key times where you’ll be transitioning into the role of DevOps engineer; either reskilling during your career or as your first job after graduating. You may have prior experience in technology, such as working as a software developer, systems engineer, systems administrator, network operations engineer or database administrator, all of which will bring broad insights and useful experience for your future role as a DevOps engineer. If you’re starting your career, maybe you’ve finished your degree in computer science or any other STEM field which will give you some of the basic stepping stones you’ll need in this transition.

I think it’s important to breakdown the broad spectrum of what DevOps engineer roles entail. Most enterprise companies today will use DevOps engineers in three different positions.
- DevOps Engineers, with a Dev Bias: Work in a software development role, building software applications. The key point is they leverage CI/CD, shared repositories, cloud and containers as part of their everyday work, but they are not necessarily responsible for building or implementing tooling. They will understand infrastructure and in a mature environment, will be able to push their own code into production.
- DevOps Engineers, with an Ops Bias: Could be compared to systems engineers or systems administrators. They understand software development but do not spend the core parts of their day building software applications. Instead, they are more likely to be supporting software development teams to automate manual processes and increase efficiencies across the human and technology systems. This could mean breaking down legacy code and using less cumbersome automation scripts to run the same commands or it could mean installing, configuring or maintaining infrastructure and tooling. They ensure the right tools are installed and available for any teams that need them. They enable teams with learning how to leverage CI/CD and other DevOps practices.
- SREs (Site Reliability Engineers): Think of site reliability engineering as having software engineers solving operations and infrastructure problems. SREs focus on creating scalable, highly available and reliable software systems.
In the ideal world, DevOps engineers will understand all the above, which is the norm at some mature technology companies. However, if you knock on the door of top tier banks or many Fortune 500 companies you’ll realize oftentimes these roles do usually have biases towards dev or ops.

Operating Systems

Whichever background you’re coming from, you should start with the fundamental technologies you’ll need to use and understand as a DevOps engineer. Linux is most likely the operating system you’ll be using daily, although some of you might be using Windows. This is where everything runs, and fundamental knowledge is important. You can install Linux at home where you’ll be able to break as much as you want and continue learning along the way.

Scripting

Next up you’ll need to pick a scripting language. There are many to choose from, such as Python, Go, Java, Bash, PowerShell, Ruby and C/C++. I suggest starting with Python, it’s one of the most popular for a reason, it’s easy to learn and interpret. Python follows the fundamentals of object-oriented programming and can be used for web development, software development, creating desktop GUI apps and even business applications.

Cloud

After Linux and Python, my next pick would be cloud, where you could choose from Amazon Web Services, Azure or Google Cloud Platform. I’d start with AWS, as they have an extensive collection of free learning tools available to take you down any track from learning about AWS as a developer to operations and even the business facing components. In fact, you might even be overwhelmed by how much is on offer when you first get setup with AWS. Maybe start with EC2, S3 and VPC and see where you want to go from there.

Programming languages

For those of you with a passion for software development. You should keep on improving your programming skills. Some good languages commonly used in this role include Python, Go, Java, Bash, PowerShell, Ruby and C/C++. You should also become familiar with tools such as Jenkins and Git/GitHub which you’ll be using frequently as part of the CI/CD process. Infrastructure is no longer left to the operations guys so you’ll need to have some exposure to a cloud platform such as AWS, Azure or GCP.

Containers

Finally, start learning about containerizing code using tools such as Docker and orchestration platforms such as Kubernetes. All the above have extensive online learning resources for free and most cities will have local Meetup groups where you can turn up and learn from experienced people in a friendly environment.

For those of you with less experience in development, you can still get involved using your passion for automation, increasing efficiency, collaborating with others and a never-ending desire to improve on your own work. I would still suggest learning the tooling outlined above, but with less emphasis on the coding/scripting languages. It will be useful to learn about Infrastructure as a Service, Platform as a Service, cloud platforms and Linux. You will likely be setting up the tools and learning how to build systems that are resilient and fault-tolerant while writing your own code.

Reskilling

If you’re transitioning into a DevOps role during your career, you should start within your company to explore opportunities. Can you reskill by working with an existing team? There might be an option for you to shadow other team members, ask for advice and reskill without even leaving your current job. This might not always be possible and some of you will need to move into another company.

If you can learn some of the practices, tools and technologies listed above, you’ll be in a good position to demonstrate relevant knowledge during interviews. The key is to be honest and to not set yourself up for failure. Most hiring managers understand you don’t know all the answers but if you can show what you’ve been learning and explain you’re open to learning more, you should be in with a good chance.

Starting Your Career

You can apply to direct open opportunities at companies who are hiring junior DevOps engineers. You will often find these companies say they’re looking for more experience and you should apply back in future when you’ve gained some commercial experience. It’s the typical, frustrating scenario of “we want more experience” but nobody is willing to give you the first chance.

It’s not all gloomy though, there are a few companies focused on training and upskilling graduates directly out of the university. MThree, where I currently work, delivers exactly that. We hire fresh graduates and train them for eight weeks in our Alumni Academy. Training covers everything from theory through to hands-on projects with Python, Jenkins, Git, Ansible, Docker, Kubernetes and AWS. By the end of the training you’ll have some solid exposure to the entire software development life cycle and a good understanding of how this applies in a Fortune 500 environment. The best part is once qualified, our teams then leverage their extensive list of clients to provide job opportunities for junior DevOps engineers. MThree pays these associates on a full-time salary with benefits for the first 18-24 months before they join the client as direct employees at the end of the agreement. This is a great way to bridge the gap from university into your technology career.

In summary, there are many ways to transition to become a DevOps engineer. This is a very rewarding career route which will likely keep you engaged and challenged as well as increasing your earning potential.

— Conor Delanbanque
August 15, 2019
Progressive Web Apps are Taking Over the Mobile Web

Consumers now spend most of their time on their mobiles, that’s no secret. And with 4G networks now the norm in both developed and developing markets, people have every reason to expect their mobile experiences will be as good as PC-based ones.

But they aren’t for the most part. Mobile web is 49% of all online traffic, but mobile conversions remain painfully low at only 1.7%. This is a sobering statistic, particularly for companies who are under growing pressure to stay relevant as customer behavior continues to evolve.

Part of the issue comes down to limitations in the user experience on mobile (i.e. smaller screens), but the bigger factor is speed. According to Google, 53% of users will bounce off a web page that takes more than three seconds to load. And yet, the average homepage still takes 15 seconds to load on a mobile phone.

Unless a customer feels an extreme sense of urgency to make their purchase, it’s unlikely they will endure the pain of waiting for page after page to load as they try to get through a purchase selection and checkout process on their phone. Neither are they likely to immediately put down their phone and dig out their laptop to complete the transaction.

Welcome to the Progressive Web

Enter progressive web apps (PWAs), the future of mobile web experiences.

While responsive web design (RWD) made most websites usable on a phone sized screen, the actual experience of interaction has proven too slow and clunky when compared to the same website on a PC. In response, many brands have developed their own mobile apps, hoping to win customers over with a smoother and more convenient service. However, aside from niche businesses with a high-touch, loyal customer-base, such as Starbucks and Facebook, most brands have spent a great deal of time making apps that are moderately successful at best, not to mention the hundreds of thousands, or even millions of dollars in development costs.

PWAs represent a significant leap forward because they allow companies to deliver the user-friendliness and page load speeds of a native app, but directly from the company’s mobile website. PWAs also make it possible for developers to create online experiences that don’t just adjust to different screen sizes but can interact with device features (such as Camera, GPS and push-notifications) creating streamlined experiences that are optimized based on which device a customer is using. The result is a more consistent experience across devices, with no features lost.

Most importantly, at a time when the war for attention has never been more intense, with PWAs, web pages load in a fraction of the time, keeping customers engaged rather than testing their patience and driving them to competitor sites.

Take the Financial Times, a company proving PWAs can have a major impact on conversion. The FT recently went the PWA route to keep pace with surging web traffic.

“One of our key metrics was speed. We determined if we made the site just one second faster, it increases engagement by 5%, and would ultimately add millions of dollars to our bottom line due to increased ad views,” said Cait O’Riordan, chief product and information officer at the FT.

Analyst houses Forrester and Gartner are also bullish on PWAs. Forrester went as far as to say there is no longer a point in arguing over which kind of mobile app is best–native or hybrid–because with PWAs taking off, nobody will bother using apps soon. Even among airlines, whose apps are some of the most useful and commonly downloaded, progressive web is seen as the future.

“Apps are a temporary necessity in the development of better mobile experiences,” admitted Scott Wilson, vice president of eCommerce merchandising at United.

Democratizing Mobile Access

In addition to supporting faster and more responsive mobile experiences, PWAs also make access to these experiences more democratic. This is particularly relevant in emerging markets such as India and Indonesia, where consumers have limited data allowances on their phones due to high costs.

Until now, this has stopped customers from downloading multiple apps. It has also limited people’s ability to engage with brands because, for many, mobile is their only portal to the internet. This is all set to change with PWAs.

PWAs demand a fraction of the data compared with traditional apps while offering nearly the same quality of experience, eliminating the access barrier and delivering a win-win for merchants and customers alike.

Why Now?

It’s no surprise the world’s leading brands, from BMW to Starbucks, have already deployed PWAs or are on the verge of doing so. Starbucks’s mobile app has long been viewed as a gold standard for customer experience and loyalty programs, but even the world’s biggest coffee chain understands PWAs are the way forward.

The wider move toward progressive web will begin in earnest over the next year. More organizations have come to appreciate the revenue risk of getting left behind and have begun to prepare for a PWAs push between now and 2025. Five years from now, mobile will easily account for 60-70% of web traffic, and customers will not hesitate to funnel towards mobile sites that work quickly and reliably. As the disruption of the past decade has shown us, heritage is no guarantee of loyalty when it comes to digital experiences.

Of course, the transition to PWAs can’t be accomplished overnight. It is a major strategic transformation that requires brands to take on a front-end rebuild of their websites. It’s also worth noting PWAs development costs can be on-par with those for a mobile app. However, unlike apps that need multiple versions for iOS and Android and require frequent updates on their respective app stores, PWAs are simply an evolution of existing open web technologies that make the web a better place both on mobile and desktop. The opportunity cost of becoming a laggard on the web is much higher than the investment cost of building a PWA.

PWAs will soon be the foundation of all digital commerce globally, and the rollouts planned over the next few years will see leading brands set a new minimum standard for customer experience. Google already added a mobile speed score to its search result rankings algorithm in 2018, and there is widespread consensus that page load times and PWA compliance will only carry more weight in Google’s rankings as more people abandon their PCs for mobile devices.

Customers around the world are also ready for better mobile experiences. With PWAs, brands will gain access to technology that will help them satisfy their customers’ appetite for speedy web experiences–and the race to capitalize has begun.

— Peter Sheldon

August 14, 2019
Leadership Drives Digital Transformation Success

When it comes to near-term survival, organizations know they are fighting for their digital existence. Still, despite 80% of organizations moving forward with their digital transformation efforts, very few have experienced the heights of success they hoped. In Digital Transformation: Coming from Behind, we reported consultancy McKinsey & Company found less than one-third of digital transformations are successful.

What makes for a successful digital transformation? Services provider Fujitsu believes its recent survey has cracked the code. With Fujitsu Future Insights Global Digital Transformation Survey Report 2019, Fujitsu found less than half of the organizations can say their digital transformation efforts have resulted in forward progress.

The survey, which spanned 900 IT executives across nine countries, also found what Fujitsu believes are the factors of success in digital transformation: leadership, ecosystem, empowered people, a culture of agility, the value from data and business integration. These are all the organizational capabilities Fujitsu identified as necessary for successful digital transformation and calls them the “digital muscles.”

While there were six digital muscles identified, there’s one essential to strengthening them all: leadership.

Leadership came on top when it aligned social and revenue goals. When survey respondents expressed what factors would improve their trust in enterprises, 67% said they would trust companies that make a positive societal impact and more enterprises indicated they’re embracing social responsibility as well as revenue. According to the survey, 72% of respondents said their companies have a responsibility to help solve social challenges in addition to the pursuit of profits and 74% said it is important that business goals and social goals are aligned.

According to the survey, 70% of respondents believe their business leaders practice empathic leadership and most management teams actively communicate with their employees. And 68% said their management readily communicates important information, and their ideas, to their employees.

Leadership also means enabling staff to do what they need to do to succeed.

“Businesses have huge unused and latent capacity of their people in their ideas and understanding of business challenges. Many people in a business have a deep understanding of certain issues, like specific customer needs, or understanding the potential of a technology, in a way that the leadership often does not. But people who perform transactional tasks, acting only as business resources, are using a minimum of their potential,” the report stated.

The takeaway for leadership is to empower employees to develop creativity, empathy, problem-solving and digital skills.

Leadership in helping employees to achieve work-life balance was believed to be important to 78% of respondents. Additionally, 74% agreed diversity is important, 72% for inclusion and 71% said they encourage their employees to act proactively.

“Companies that recognize the importance of these factors seem to have greater success in digital transformation,” the report stated. “A good work-life balance enables employees to work with a sense of fulfillment. They can be motivated to transform. Taking advantage of diversity can help companies to attract talent and to form more creative teams, which brings creativity and innovation,” the report continued. “In addition, companies emphasizing inclusion earn the respect of individual employees and encourages greater sharing of ideas and opinions. Creating a corporate culture that motivates employees to innovate will help drive digital transformation.”

Finally, the report found leadership that helps build their people’s ability enjoys better transformational outcomes.

From those companies that support a work-life balance and diversity, 41% said they delivered good digital transformation outcomes. However, for those that didn’t place importance on work-life balance and diversity, only 19% and 22% respectively had good digital outcomes.

“Among companies that emphasize inclusion, 40% said that they had delivered digital transformation outcomes, whereas for companies that do not regard inclusion as important, the figure was only 24%,” the report said.

The survey shows leadership that primarily focuses on technology transformation and don’t focus on helping their employees enhance their capabilities as part of an organizational transformation, risk falling behind those organizations that do prioritize employees.

— George V. Hulme

August 13, 2019
How Product Managers Can Take Back Control with Feature Flags

Product managers live in a high-speed world and are always focused on releasing the most impactful features in the shortest amount of time. Since users have grown accustomed to regular UI updates and bug fixes completed in near real time, this frenetic pace at which product managers work will only increase.

The process of pushing out new features or software fixes can be very stressful on product managers, and the one thing they crave to keep their sanity and ensure a successful release is control. Luckily, that’s exactly what feature flags provide.

Dialing Up Feature Flags

At their core, feature flags give development teams the ability to turn features on and off without deploying new code. Think of them as dials in the cloud. When the dial is attached to any feature in a product–whether a new one or an old one–it controls who sees it, who has access to it and how quickly it is delivered to an entire customer base.

Feature flags let organizations break the tyranny of the Thursday night release by segmenting it into smaller bits to control exposure and enable a continuous release motion. You might start by turning on a feature to only internal users or beta testers so you can test in production to make sure nothing has been missed. From there, you have the freedom to ramp up the feature to your customers gradually before going to 100% availability.

With this controlled exposure, development teams can lessen the panic and anxiety around the weekly release schedule. Having the ability to completely turn off features means feature flags also increase application stability and remove the need for hotfixes. It’s less often necessary to assemble a war room if there is a problem when you can simply turn off the feature in seconds. By working feature flags into the release process, teams take control of the who, what and when in terms of releases. They can also dictate types of users, demographics, locations and scale the release of the new feature.

Feature Flags and Product Managers

Outside of the DevOps team, feature flags can also be really powerful for product managers. Historically, the release of a new feature meant product managers had to coordinate with cross-functional teams to ensure the release was executed successfully. This meant making sure marketing was ready to publish a blog post about the feature, the sales team knew how to use and sell the new feature, and the product marketing team had documentation prepared for how the feature set works. Of course, all of this had to be perfectly synchronized with the engineers’ timeline for releasing the feature.

With feature flags, product managers now essentially have the keys to the kingdom. It gives them the power to turn the feature on for some or all of their customers without waiting for engineers to complete their next deploy. Not having to coordinate that extra piece of the schedule gives a lot of power and time back to the product manager.

A Deeper Look at Customer Feedback

Another aspect of a product manager’s job is collecting feedback. They need to be able to answer questions related to business KPIs, such as “How is this feature performing for my customers?,” “Are customers able to do the action the feature is intended to perform?” and “Are we generating more revenue from the feature?” Feature flags can also help in this area.

As product managers ramp up a feature, they are simultaneously shortening the feedback cycle. Since feature flags allow for segmentation, where one customer group sees one set of features and another customer group sees a different set of features, and since key metrics can be captured into separate buckets for each group, product managers can now run controlled experiments as part of the release cycle. Seeing KPIs aligned with the different customer groups helps them understand which features are performing the most successfully.

Creating the Ideal Product Roadmap

As product managers embrace usage measurement tied to feature rollouts, entire teams can better align with agile best practices to continuously push out the smallest incremental set of new features. By understanding the performance of every feature, you’ll be better equipped to iterate and refine your ideal product roadmap.

— Dave Karow

August 13, 2019
FaaS is Key to DevOps Efficiency

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

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

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

Back to Focus

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

The impact for DevOps is immediately apparent.

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

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

Speedier Implementation

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

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

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

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

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

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

FaaS Challenges

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

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

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

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

The FaaS Road Ahead

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

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

— Mike Duensing

August 13, 2019
BMC Extends DevOps Reach to Db2 Databases

BMC Software is extending the reach of its campaign to bring DevOps to the mainframe to the IBM Db2 databases that run on the venerable platform.

John McKenny, senior vice president, ZSolutions Strategy and Innovation at BMC, said BMC AMI DevOps for Db2 makes it possible for DevOps teams to automate changes to the Db2 schemas as part of a pipeline being employed on a Jenkins continuous integration/continuous development (CI/CD) platform.

As part of its effort to bring DevOps processes to the mainframe, McKenny said BMC is trying to bridge the historical gap between DevOps teams and database administrators. Many DevOps teams have tried to bypass DBAs that they often perceive to be to slow to keep up with agile development processes. In mainframe environments, however, Db2 databases remain the primary source of data for applications. BMC AMI DevOps for Db2 automatically discovers and determines database schema change requirements, streamlines the review and approval process and implements those changes, he said.

BMC AMI DevOps for Db2 is part of a portfolio of BMC automated mainframe intelligence (AMI) tools that leverage a policy engine to enforce best practices for database schemas. Those tools play a critical role in enabling organizations that continue to rely on mainframes to capture those best practices at a time when many of the IT professionals who defined those best practices are retiring, said McKenny, adding BMC will evaluate whether it will add support for other mainframe databases such as IMS based on demand.

It’s unclear how much or even whether organizations that rely on mainframes are embracing best DevOps processes. Providers of tools for mainframe environments such as BMC are betting digital business transformation initiatives will require those organizations to replace their current application development and deployment tools and processes with DevOps processes, which are more agile. The challenge, however, is overcoming the perception that existing waterfall approaches to application development and deployment result in more reliable software. As a result, many organizations that rely on mainframes are trying to determine which methodology to employ based on the nature and criticality of the application workload.

At the same time, BMC is investing in various forms of artificial intelligence (AI) to automate IT operations, otherwise known as AIOps. Naturally, BMC is not the only provider of IT management frameworks with similar ambitions, but it contends that after decades of providing tools to manage both mainframe and distributed computing environments, it’s in a better position than its rivals to aggregate all the data required to drive the models that are at the core of any AIOps platform.

Of course, it remains to be seen to what degree IT organizations are comfortable with AIOps. Beyond the perceived threat to their jobs, many IT professionals are skeptical AI models are sophisticated enough to automate complex IT processes reliably. The one thing that is clear is that with the simultaneous rise of DevOps and AIOps, the way IBM platforms have been managed is about to change utterly.

— Mike Vizard

August 12, 2019
Why Modernizing Security is Like Visiting a Fast-Food Restaurant
Fast casual restaurants are taking over the food industry. Today’s consumers want quality and speed, and the brick-and-mortar model offering immediate service paired with quality ingredients perfectly fits the bill. It’s the new, modernized dining experience. You can also argue that the same modernization taking the food industry by storm is happening in the security sector.

Simply put, fast-food restaurants know what their customers want: food that’s served hot, fresh and quickly–all while being made to order. And while the needs of a fast-food customer may seem far from the security needs of an organization, it isn’t too far off. Just like a fast-food customer, DevOps teams are hungry for a streamlined process. However, in their case, this doesn’t come in the form of a fried chicken sandwich; rather, an app infrastructure that is low-latency, secure and brings visibility.

According to the 2018 Verizon Data Breach Investigations Report, web application attacks are the leading source of data breaches. This suggests security procedures are not keeping up with modern systems and vice versa, which means they’re not keeping up with the modern customer, who has increased security needs due to demands for fast, interactive, web-based experiences with vendors. From food service to security, many industries are learning that, to succeed today, you’ve got to combine the old with the new.

As technology evolves, systems must as well. When it comes to security, it does not make sense to continue using a legacy WAF built for a decades-old line of defense. Today’s technology and applications require next-gen WAF systems that can keep up with the changing infrastructures and the evolving threat landscape. The risk is too great to sit back and do nothing.

Security teams today often find themselves either supporting new infrastructure initiatives or inheriting legacy applications and systems. Determining where an application is running can be a challenge. Rather than simply pointing to a rack of servers to locate an app, security professionals now must look to the cloud. However, this presents another obstacle: container orchestration. Kubernetes or otherwise, the options are not always clear-cut.

A modern infrastructure mix is made up of many parts (much like a layered chicken sandwich): cloud, containers, hardware, platforms—and sometimes serverless. Flexibility and deployment options are essential to defending applications and APIs across multiple components and delivery stacks. Typically, security teams end up in a balancing act of supporting new infrastructure plans while taking over existing legacy systems and applications.

To be adequately protected, security teams must evaluate defensive tools, open source or commercial, for use in:
- Major cloud providers (e.g. AWS, Azure, IBM, GCE)
- Container platforms (e.g. Kubernetes, Docker)
- Hardware and web servers (e.g. load balancers, NGINX+)
- Serverless options (e.g. API gateways)
- Platform services (e.g. Heroku, language plugins)
- Cloud-based deployment models (e.g. hosted cloud WAF)
The modern world is ever-evolving and the definition of “modern” changes as new technology is introduced. Fast-food chains have evolved over the years and, in turn, moved the food industry forward with the introduction of fast, casual and reliable options. The companies continue to evolve to meet the customers’ demands by introducing delivery services, unique rewards programs and leading mobile apps.

The security world can learn a thing or two from the fast-food chains’ commitment to continued business evolution. Much like the way fast-food customers are quick to jump ship if they don’t see the selection they want, legacy WAF customers are learning they can make a change to other security solutions if features and infrastructure aren’t evolving.

The simple truth is legacy WAF solutions can’t accommodate today’s technology and applications, exactly how traditional fast-food can’t keep up with customers’ growing demand for tasty yet quick meal options. This leaves proprietary data exposed and vulnerable to attacks. It’s time for security leaders to take action and upgrade their systems while getting their teams up to speed without sacrificing security of their vital assets.

— Jonathan DiVincenzo
August 12, 2019
Embracing the Product Development Cycle

Nowadays, a truly successful product calls for purposeful investment in the people that will ultimately use it in their specific environments.

We all know technological development is hyperactive and unpredictable. Ultimately, we want to be able to create cutting-edge tech, deploy it wherever it’s needed and have it operated by skilled staff that understand all the nuances. We need to be able to move fast, adapt on the fly and do so with security mechanisms that fire on all cylinders–irrespective of environment.

The best way ahead is to actively engender a more informed user base that can apply experience and context. There are big benefits to be had by doing this. With the right investment and infrastructure, the aim is for informed and confident end users to form symbiotic relationships with the vendor, helping to guide product and solution development on an ongoing basis. Operational challenges are not static, so the technology in place to meet them certainly shouldn’t be.

Vendors need to embrace the mindset that a product’s lifecycle needn’t be clunky, disrupted by diversions or constrained by boundaries. It is all about continually engaging and listening to every contributor to a product’s existence: customers, partners, engineers, support staff–the whole ecosystem. Collaborate, innovate, feedback, improve and repeat. The future is a dynamic continuum of constant innovation and improvement.

As part of F5’s transformation to a multi-cloud application services company, we had to train hundreds of engineers around the world with a new set of foundational skills in cloud, automation, orchestration and DevOps methodologies. Essentially, the process entails developing training content to test with a selection of key users. Areas of improvement are identified, and these are then built into the product. The cycle is repeated.

It may sound simple but you’re not going to get the substantive, actionable feedback you need without instilling the right culture. For this, you need a lot of training and documentation. You need to guide the way with strategic credibility and maintain confidence. Above all, you need to be patient and listen.

At F5, we’re constantly building out the mechanisms for how we train in conjunction with our development efforts. A big part of that is integrating adequate feedback loops—both on the training and products front. If a customer hits a wall, what did we learn? How can we contribute via open source? How do we leverage what we learned to make our products and people better?

We’re not just building automation and orchestration solutions. We’re aligning to the methodology around DevOps and the software process. We’re designing as if it were a giant distributed software project that happens to run on and integrate with the F5 platform. All of this gives us the means to start a new conversation with customers, one that is entirely based on how to achieve successful outcomes. Sometimes we may assent to, for example, the introduction of a new feature. Sometimes, we’ll push back. We will always be agile, adaptable and collaborative. It is never anything less than an eye-opening journey. It needs to be. We have no interest in directionless wheel-spinning, nor do our customers.

Another major benefit of our approach is it explicitly and effectively helps NetOps become a true partner of DevOps. This means projects are no longer bounced around in silos, bottlenecks are eliminated and the results speak for themselves. Going through this process and making these shifts have fundamentally changed F5’s ethos and identity. We had to change in order to fully engage with the bleeding edge, with the way container ecosystems are built, the way microservices are built or the way software is developed in the modern age.

— Hitesh Patel

August 9, 2019
A Culture-Driven Approach to DevOps Transformation
One of the most challenging aspects of a DevOps transformation isn’t automating and overhauling technology. The biggest challenge of DevOps is changing an organization’s culture and purpose. You can’t “buy a DevOps.” DevOps demands the involvement of people, process and tools working together.

Unfortunately, I’ve seen too many companies get carried away with the latest shiny object and neglect the people aspect. So, the end results they were expecting do not come to fruition. Research from Google Cloud and Harvard Business Review supports the importance of a people-first DevOps strategy. This research confirms DevOps transformation projects are worthless without addressing the people aspect.

Of course, such large-scale transitions are difficult. People have to put their reputations on the line to sell the transformation. Employees may become stressed or resist the cultural changes that come with a DevOps transformation. Therefore, communication throughout the entire transformation must be your primary goal. Communication includes measuring the effectiveness of the transformation vision and goals and sharing that information with your team. Keeping them informed ensures they understand the critical role they play in this vision, as well as the value of their work. These measurements need to also show how participation in change translates to value for the business.

Here are some best practices for prioritizing people and process when working through your DevOps transformation.

Communicate Every Step of the Way

It’s important to establish a level of empathy for your employees and understand exactly how changes will affect them. Employees’ professional identities develop over many years, and you can’t expect them to change overnight. Here are some questions your employees are wondering about:
- What happens to my job when we have to start adhering to this new process?
- Will I lose my job when all this automation is implemented?
- How am I going to learn the skills to be effective and contribute to this new way of working?
Expect their questions and listen for more areas of concern. Be proactive about sharing both the questions and the answers with everyone.

It’s critical that you keep an open channel of communication with your employees to help them through this change. Don’t view this as an add-on exercise–it should be the cornerstone. Focus on communication, and devote time to your staff, so they are completely integrated into the new DevOps process.

Your communication strategy needs to include all the teams involved with application delivery. Hold regular meetings across all departments, not only development and operations teams. Think about how the DevOps transformation impacts departments such as marketing, human resources and finance. What challenges have they run into? Have there been any negative impacts thus far? Listening and addressing each issue in real time will ensure the transformation is moving in the right direction.

Measure What Matters

When it comes to measuring your success, don’t worry about what other companies may be doing. The metrics that matter are the ones that support your ultimate business goal, which in this case is a better software delivery process.

Identifying metrics for your business demands you understand how your company’s process drives behavior. Ask questions such as: What corners were cut to get from development to production on time? Did meeting this deadline impact the timelines and performance of other teams and the quality of other applications?

Meaningful metrics allow you better insight into your processes in the real world. And meaningful metrics help determine whether your pipeline is moving in the right direction to deliver high-quality, high-value software.

Remember those regular meetings I mentioned earlier? These are also a great time to focus on metrics so employees understand how their work impacts the business. It’s also an opportunity to hear what’s happening on the ground in the delivery pipeline. This real-world information can determine progress, as well as test if the right metrics are being tracked.

Conclusion

A DevOps transformation requires changes to staffing, organizational structure, performance and culture. As a result, the success of your transformation involves moving the entire organization forward—building a strong culture ensures all people at all levels are invested in it. Measuring and communicating results must be the standard for every release you do.

DevOps can fundamentally change any organization for the good. By continually communicating a clear vision of the goals and expectations of your transformation, people will feel confident they are on a winning track.

— Tj Randall
August 9, 2019