Akamai today extended its DevOps strategy to provide tighter integrations with continuous integration/continuous (CI/CD) platforms and IT automation tools such as Terraform from HashiCorp.
In addition, Akamai is adding support for serverless computing functions to Akamai EdgeWorkers, a JavaScript-based framework through which application logic can be executed on the edge of the Akamai content delivery network (CDN) now as a microservice.
Greg Griffiths, product marketing manager for DevOps solutions at Akamai, said the latest additions will make it easier for DevOps teams to view the Akamai CDN as a natural extension for deploying applications. Akamai launched its first DevOps initiative last year. The goal is to make possible for DevOps teams to spin up new properties and make configuration changes from within the context of their CI/CD workflows, he said.
Terraform support, meanwhile, will make it possible for DevOps teams to programmatically provision and manage properties and DNS zones as code, added Griffiths.
As part of that effort, the Akamai Pipeline can now synchronize with the Akamai Control Center to capture any manual configuration changes in a way that then allows them to be incorporated into a CI/CD workflow, he noted.
Akamai has been making a case for deploying applications as close to the network edge as possible using its CDN to reduce network latency. As part of that effort, EdgeWorkers allows developers to spin up microservices as needed. Those microservices can now access data embedded in the function, including all the data from the HTTP request such as cookies, headers, URL and query parameters.
DevOps teams can now also more easily conduct A/B testing and feature experiments using cached content in addition to delivering different application experiences by modifying the path to cached images and other content based on variables such as customer location or time of day.
Other new capabilities being added by Akamai include the ability to modify both the path and query arguments for a request and determine to which origin any request should be routed.
Griffiths said now that more organizations are leveraging the Akamai CDN as a vehicle for delivering applications at the network edge, the next big initiative will be to make it easier to leverage the company’s managed security services to embrace DevSecOps.
It’s not clear to what degree DevOps teams have embraced CDNs as a vehicle delivering applications. Organizations have, however, been leveraging CDNs to deliver web applications for years now. By providing tighter integration with CI/CD platforms Akamai is essentially making the CDN just another target for deploying applications at the end of a DevOps workflow. That capability may prove critical as organizations move to deploy more application code on edge computing platforms involving use cases that require data to be processed and analyzed in near real-time.
Of course, Akamai is not the only CDN providers with similar ambitions. It is, however, already the largest, so from a DevOps perspective most organizations will soon encounter an Akamai point of presence somewhere soon, if they have not already.
Quick Base, a provider of a platform for building low-code applications, announced this week that it is making its platform available for free through Sept. 30 to first responder organizations that need to build applications quickly to address the COVID-19 pandemic.
Jay Jamison, chief product and technology officer for Quick Base, said it’s apparent first responders soon will need applications to track things ranging from assets such as ventilators to heat maps that show the number of patients in a geographic area relative to the number of intensive care units (ICUs) available.
Quick Base is also making available templates that can be employed to build the most common types of emergency response applications, such as ones already being employed by the City of New Orleans.
Examples of other applications that will be needed include the ability to track businesses in real-time that may be flouting COVID-19 restrictions or landlords that are evicting tenants despite emergency decrees, noted Jamison.
Most of these applications will need to be developed in days versus weeks or months. To that end, Quick Base is also making available to first responder organizations the expertise of its internal customer success staff as well as third-party consultants, he said.
In addition, Quick Base plans to certify many of these applications for distribution via its online store, which will make it easier for a first responder organization in one locality to leverage an application that has already been developed by another first responder organization.
In general, Jamison said first responder organizations will need to apply DevOps principles across their entire organization to adjust to highly fluid situations. Applications undoubtedly will need to be modified as processes evolve and new emergency decrees are declared, he noted.
The biggest challenge from an IT perspective is many first responder organizations lack the process expertise needed to build an application on the fly. Volunteers with IT expertise will be needed to work alongside medical experts, who will need applications that most likely will be deployed in the cloud but made accessible via a range of mobile computing devices. The chances all those applications will work perfectly when first deployed is almost nil, so timely updates to applications will be critical.
Of course, applications and IT processes are not always the first things that come to mind to combat a pandemic. However, the faster first responders can respond to changing conditions on the ground, the more lives that might potentially be saved. In some large cities, it’s probable first responders already have access to a range of applications that to vary degrees might scale to meet the current challenge. However, in smaller localities, the availability of such applications is nominal at best.
Quick Base is not the only provider of low-code and no-code tools for building applications, so there are plenty of options for building applications quickly. Whichever the platform employed, time is going to be of the essence. Outbreaks in Italy, Spain and China have already shown how quickly events can spiral out of control. If any new application is going to be relevant in any other emerging CIVID-19 hot zone, the work to build that application needs to start immediately.
Tasktop this week announced the general availability of an application to manage projects based on a flow framework that captures events as they occur across the software development toolchain.
Company CEO Mik Kersten said Tasktop Viz is the first substantiation of the flow framework in software that provides a value stream management application to enable organizations to more effectively manage software development projects. Tasktop Viz doesn’t necessarily replace project management software as a system of record for billing purposes, for example, said Kersten; however, it does provide a way to visually model the software development environment in a way that makes it easier to identify bottlenecks and potential opportunities to reallocate resources.
Kersten said from a management perspective, existing approaches to managing software development projects are broken. They depend too much on software developers to manually enter data to update a project management application, which they don’t do as often as they should because it takes time away from developing software, he said. Tasktop Viz takes advantage of application programming interfaces (APIs) to automatically capture metadata from across the software development toolchain, providing instant visibility into software development projects without requiring DevOps teams to engage in an additional coding, Kersten noted.
Kersten has been making a case for the adoption of an approach to managing software development projects based on the flow framework for several years. Tasktop Viz now provides IT teams with an application that is designed from the ground up using that model.
Of course, the concept of value stream management applications has been around for some time. The debate now is not so much over the value of these applications as much as it is which architectural approach to building these applications best reflects modern software development. As the number of dependencies between projects continues to expand, it’s becoming next to impossible for organizations to manage multiple software development projects relying solely on spreadsheets and existing project management applications.
That issue is further exacerbated by the fact that businesses are now more dependent on software than ever, so any delay to a project could have a dramatic impact on future revenues.
Kersten said that despite the obvious business benefits, the biggest obstacle to adoption is more psychological than technical. Many software development teams are reluctant to adopt tools that might illustrate how chaotic the software development process within their organization really is. It’s critical that organizations that adopt value stream management applications do so with an eye toward wanting organizations to improve rather than just deploying another tool to measure metrics that are used to increase the amount of code being written.
Of course, there’s no correlation between the amount of code being written and the quality of the applications being developed. The real challenge is to not just accelerate the rate at which applications are being developed, but also to ensure that once those applications are deployed in a production environment the number of fixes required are kept to the absolute minimum possible.
Atlassian announced today it has added a no-code tool to enable DevOps teams to make it easier to customize Jira project management software without having to learn how to code.
Sean Regan, head of growth for software teams at Atlassian, said Automation for Jira will now become a core part of Jira Cloud that will be made available to all 65,000 customers using Jira software. Originally developed by Code Barrell, the tool was acquired by Atlassian last year. Previously, it had been available as an add-on adopted by about 6,500 customers, he said.
The goal is to enable administrators that track projects to reduce the amount of time they spend on manually entering data. On average, organizations are spending 51 hours a month on administrative tasks involving the management of projects, Regan noted. Organizations should take inventory of those tasks and use Automation for Jira to start automating the tasks that are the most repetitive, he said.
Automation for Jira, Regan said, is part of a larger ambitious effort to make Jira software accessible to more than 100 million active end users. By employing a visual tool to automate tasks it should become easier for a broader number of organizations to customize processes by defining rules that trigger events. Organizations will not be forced to depend on developers to write code to create those workflows, he noted.
Automation for Jira is also part of a concerted effort to modernize a venerable Jira project management application that has been widely employed by software development teams for decades. The ultimate goal is to enable software development teams to spend more time building applications versus trying to ascertain the status of any given development project, said Regan.
The no-code Automation for Jira tool is also designed to integrate with collaboration tools Slack and Microsoft Teams within the context of a set of best DevOps practices. In fact, Regan noted any time there is an issue on a software development project it almost always comes down to a lack of collaboration between all the stakeholders involved.
There is, of course, a lot more appreciation for project management software among DevOps teams that typically are trying to organize around multiple projects at the same time. A delay on one project might present an opportunity to reallocate resources to accelerate another. That can’t happen, however, if no one is aware of what bottlenecks exist in the first place.
Not everyone appreciates all the nuances of project management. The less obtrusive project management becomes the more effective it tends to be. Developers are especially notorious for not always updating project management applications, which usually results in project managers having to nag them to share information that other teams are counting on before they can move forward. Hopefully, there may come a day when all project management applications are updated automatically. In the meantime, the less time spent on manual tasks the happier all the members of the software development team are likely to be.
Kubernetes and Docker are two of the most commonly heard buzzwords in modern DevOps conversations. Docker is a tool that enables you to containerize and run your applications, and Kubernetes provides you with a platform to orchestrate or manage these containers—since managing thousands of containers manually using the Docker CLI would be a practical nightmare.
However, simply running thousands of containers and managing them through Kubernetes is not enough. You have to observe and analyze them properly to ensure that your services are up and running optimally. This process is called Site Reliability Engineering (SRE), a term initiated and popularized by Google. Observability and analysis are a major element of SRE. It can be subdivided into the following three areas:
Monitoring allows you to extract numerical metrics from your applications and resources that can later be visualized and analyzed to present the current state of your resources. Once the metrics are extracted, they can be used to set up alert rules, facilitate profiling and debugging, and make better SRE decisions.
Logging enables developers to debug their containers in case of a failure. Containers are short-lived, and so are logs. Kubernetes and Docker do provide a native way of browsing container logs, but it is very limited in its functionality. As a result, a centralized log plane is a must in any container-oriented environment.
Tracing allows you to debug services running on a network and follow a request trail until the source of a problem can be determined. In a microservices architecture, when multiple services/containers send requests to each other to perform one business task, a proper tracing solution is necessary.
This article will list and describe the most effective open source tools for monitoring and analyzing services running as containers.
Prometheus
Prometheus is the first tool that comes to mind when discussing open source monitoring solutions. It is very popular in the development community, and it is a graduate of the CNCF project, which focuses on the monitoring side of SRE. Originally created and open sourced by SoundCloud, Prometheus simplifies the process of pulling numerical metrics based on a time series from a given metrics endpoint. It was built to monitor highly dynamic container environments.
Prometheus is subdivided into three elements: Prometheus server, Alertmanager and exporters. Exporters are stand-alone, independent processes/containers that can be run on your target resource to generate and export metrics via a metrics API. The Prometheus server then takes care of service discovery as well as pulling metrics from the exporters to be stored in the Prometheus DB and later used for visualization or alerting. Alertmanager is responsible for setting up alert rules, analyzing the data in the Prometheus DB and sending alert messages to multiple receivers if a certain rule is triggered. There are a huge number of exporters, listed here, which are both officially supported by Prometheus and maintained by the community.
Prometheus has become the industry standard for monitoring cloud-native architectures. While it is known for its simplicity with service discovery, its ease of use, its alerting capacity and its integration with Kubernetes, its polling architecture is not ideal. Currently, the metrics endpoint has to be reachable by the Prometheus server. However, there is a pushgateway implemented in Prometheus that enables metric pushing rather than polling. Another downside of Prometheus is that it doesn’t scale well. This problem can be fixed in the Thanos adaptation of Prometheus.
Related tools and technologies: Grafana, Cortex, Thanos, Prometheus Exporters, Alert Manager, Istio, Prometheus Operator.
Grafana is an open source metric analytics and visualization suite. It allows you to create custom dashboards using data taken from multiple sources, such as Prometheus, Elasticsearch, MySQL, Postgres and Redis. Furthermore, Grafana has its own alerting system and a role-based access control (RBAC) system for software. As a data visualization tool, Grafana is famous among Prometheus users for enabling them to effectively visualize the metrics stored in Prometheus. There’s a wide array of official and community-built custom dashboards for various data sources in Grafana, allowing users to easily set up dashboards (found at this link) and get on with monitoring. Grafana offers another associated product called Loki, which aggregates logs in Kubernetes and integrates well with the Grafana UI.
Related tools and technologies: Loki, Prometheus.
Figure 2: Kubernetes Resources Dashboard in Grafana. Source: Replex.
Elastic Stack
Elastic Stack is a group of open source products from Elastic designed to help users search, analyze, and visualize data from any type of source, in any format, in real time. This product was previously recognized as the ELK stack, where each letter of the acronym stood for one of the company’s main products: Elasticsearch, Logstash and Kibana. Elastic Stack provides both monitoring and logging solutions with the help of its big data database, Elasticsearch.
In order to aggregate logs, people tend to use Elasticsearch for storage, Logstash or Fluentd for log streaming, and Kibana for visualization. Fluentd is not part of the Elastic Stack, but it is widely used with Kubernetes to stream logs in place of Logstash, the tool provided by Elastic Stack. Similarly, Metricbeat is used to scrape metrics and set up visualizations on Kibana. The enterprise version of Elastic Stack ships with X-Pack, a set of additional tools that enables reporting, alerting and role-based access control (RBAC), among other features. By default, the Elastic Stack GUI, Kibana, does not support RBAC. You have to use the previously mentioned enterprise version of Elastic Stack to enable it.
Related tools and technologies: X-pack, Metricbeat, Logstash, Kibana.
Figure 3: Discover View in Elasticsearch. Source: XpresServers.
Sensu Go
Sensu Go is a telemetry and service health checking solution for multi-cloud monitoring at scale. It allows you to gain visibility into servers, containers, services, applications, functions and connected devices across any public or private cloud. Sensu can be run side-by-side with Prometheus to get the best out of both solutions, or it can be run natively without Prometheus. Sensu works best alongside Prometheus, since exporting application level metrics to Prometheus requires loading the Prometheus SDK to your application codebase and exposing a metrics endpoint. The endpoint is then scraped and stored in the Prometheus Server. This may sound like a lot of work—and, sometimes, it is. Sensu avoids this complexity by using a sidecar concept. A Sensu agent is deployed alongside your application. The agent constantly collects and exposes metrics to the Prometheus server without your having to change the application codebase.
Sensu works without Prometheus too. It can operate natively in Kubernetes, where it has its own server to store and visualize metric data exposed by the previously mentioned Sensu agent.
Sysdig has two open source products: Sysdig Inspect and Falco. Here, we’ll focus on Inspect, which monitors and captures the container processes running in your system and allows you to drill into those processes for post-incident forensics. This enables you to analyze your application performance, troubleshoot errors and monitor any processors that could be misbehaving. Furthermore, if your system is breached, Sysdig allows you to understand how the breach occurred and what data was taken in the process. Sysdig Inspect is a very powerful tool that focuses on the performance tuning and security investigation of your system.
Related tools and technologies: Grafana, Sysdig, Sysdig Falco.
Jaeger is an end-to-end distributed tracing solution that was open sourced by Uber Engineering. It allows you to monitor and troubleshoot transactions in complex distributed systems. In modern microservice architectures, the majority of operational problems fall under the umbrellas of networking and observability. When a service failure occurs, you have no idea how the requests have gone from service to service over the network to complete a single business transaction. This makes debugging extremely difficult. Currently incubating under CNCF, Jaeger uses tracing to enable root cause analysis, performance and latency optimization, and distributed transaction monitoring. Jaeger works out of the box with Istio, a popular service mesh implementation open sourced by Google.
Related tools and technologies: Prometheus, Jaeger, Zipkin, Istio.
These tools are widely used in the tech industry, and they all have their benefits. Most of these solutions, however, require skilled implementation and ongoing manual maintenance that can be a burden for DevOps teams and a distraction from the business. There’s no one solution that can cater to all of your requirements, since each tool focuses on one or two specific aspects of observability and analysis. By mixing these tools together, you can derive a unique solution for your individual business needs.
For ease of comparison, the chart below outlines the features offered by each of the tools discussed in this article.
The rise of DevOps is starting to have a significant impact on the rate at which databases now need to be deployed and updated. A global survey of more than 2,000 developers, database specialists and IT leaders conducted by Redgate Software, a provider of tools for automating the management of databases, finds nearly half (49%) are now deploying database changes in production at least once a week or more.
Kendra Little, DevOps advocate for Redgate Software, said most of the changes are being driven by the adoption of best DevOps practices that are now having a cascading impact on other functions in the IT environment.
However, the survey shows the adoption of DevOps remains uneven. Only 18% of respondents said they have adopted DevOps across all projects, while 36% said they have adopted DevOps across some projects. Another 14% said they are at the proof-of-concept stage. Only 13% said their organizations have no plans to adopt DevOps at all. Survey respondents in the financial services and insurance industry sectors have the highest levels of adoption, with more than 77% of respondents saying their organizations are either in proof of concepts (16%), have adopted across some projects (41%) or have adopted across all projects (20%).
Progress appears to be rapid among those that have adopted DevOps. Well over a third (37%) report that only 1% or less of their deployments introduce code defects that require hotfixes. That compares to 30% for all other groups.
The survey also revealed that more than half of respondents (55%) perform most or all of their business-critical database deployments while their systems are still online, with 75% of that group reporting that 10% or less of those deployments caused defects that require hotfixes. Nearly half (46%) are also employing some of automation to deploy databases, according to the survey.
Nevertheless, the survey makes it clear challenges remain. Disruptions to existing workflows and business was cited as the top barrier to adoption (23%), followed by lack of skills (22%) and lack of alignment between developers and operations (16%).
Little said the survey makes it apparent that database management needs to become more aligned with the software development life cycle (SDLC) with organizations transitioning to DevOps. Over a quarter of respondents (26%) said it is still somewhat or very difficult to get code reviews for database changes. A further 16% said that no code reviews are done for database changes early in the development cycle.
Less clear is who precisely is managing the database. Developers in the Age of DevOps are exercising more influence over what databases are employed. However, Little noted that 43% of organizations still have a database administrator managing their databases. That compares to 34% that rely on developers and 21% that have a combination of both. Over time, Little said most organizations will continue to shift toward a combination of both. That, of course, will require a significant amount of cultural change within most IT organizations, where all too often developers have tended to view DBAs as a bottleneck to be eliminated whenever and wherever possible.
One of several iterations that IT likes to go through is corporate standards for technology versus best tool for the job. We like to have standardization because it allows staffing portability between projects, but we like right tool for the job because from the moment you choose a standard, competitive factors and changes in needs make the standard less of a big win.
DevOps is still struggling through this process, particularly in enterprises where standardization bears a bit more weight on important projects.
The fact is that DevOps is well suited to the idea of iterating standards–somewhere between a wild west of everyone using their “right tool” and an organization dictating the tool of choice.
Most of us use Jenkins, because it does what we need it to do. What needs doing is different from organization to organization–some use it for continuous testing, while others go all the way through application release automation. But the fact is we could iterate and replace some, or all, of the functionality we’ve decided to use Jenkins for tomorrow. Kind of like a “We have a standard that is evaluated regularly” approach.
For those new to DevOps, the array of choices is downright bewildering. Xebia Labs has a toolchain diagram page to help those already doing DevOps, and several sources have spreadsheets/PowerPoint templates to help you work through your existing environment. While all of the options these tools try to organize for you are great for the industry to find better solutions, it makes for a confusing mess. Your toolchain could be all AWS with some scripting, all Jenkins with plug-ins or 15 different apps working independently. A surprising number of organizations are even using Git for the bulk of their toolchain.
What matters is that you know what you have, and know what your options are. Build the best toolchain for your environment today, and keep half an eye on it to be aware when something more suited to your environment comes along. We still maintain python scripts that do a fair amount of our automation, but several toolsets in place also.
There are objectively better tools out there, but for our purposes they are almost universally overkill. So we go with what’s best for our environment. As time has gone on, we’ve integrated more and scripted less, but it will be a while before out toolchain is actually just tools–if ever.
If your toolset is doing the build/test/deliver/deploy cycle well enough, you’re covered. If it’s not, you need to look for alternate solutions. Even if it is, make sure you’re aware of what’s on the market and not just what’s “hot” right now. Be aware of those companies that are up and coming, maybe in spaces that are already flooded. What differentiates them, and in our environment would that differentiation matter? That’s all you need to know–there is no need for a super deep technical evaluation, unless you’re actually considering them. Just enough to know if their differences add value.
Keep cranking out the apps that make business run. Perhaps with an updated toolchain, perhaps not. In the end, what works for your environment is all that matters.
DevOps teams are expected to do more work in less time. They need to plan, test, build, secure and release applications at a fast-paced rate. Of course, the DevOps team needs to achieve all of this while maintaining high software quality. This is why automation is a crucial part of the DevOps workflow. The goal is to delegate repetitive tasks to the machine, and free up dev time for more complex jobs.
Below are some helpful automation hacks you can apply to boost the effectiveness of your DevOps practices.
Automating Regulatory Compliance
Properly managing regulatory compliance is vital for many organizations to avoid fines and operate legally. Although compliance standards vary by industry, most focus on ensuring privacy and confidentiality. To meet these standards, companies must secure data and prove they are taking the appropriate measures. This proof is commonly accomplished with the maintenance of a clear digital trail.
You can use DevOps automation to log and store digital access trails for your protected data. You can also use automated testing and deployment to ensure that only code that passes compliance tests is deployed. This prevents compliance issues from being pushed to production and helps keep your data secure.
Automating Development Environments
DevOps workflows require frequent creation and elimination of environments, for testing, deployment and development. These environments can be created manually but it is more efficient to create environments automatically. This can be done using a golden image with your required configurations.
Using standardized base images ensures that you are working with consistent environments and standardizes configurations and privileges. These images can be used for local or remote machines and can be initialized automatically.
There are a variety of tools you can use to create and automate environment creation. Chef and Vagrant are two of the most popular. Both of these tools offer an accessible API and enable you to script automation using common languages and syntax.
Automating Code Review
Code review is an essential part of DevOps processes but it is also one of the lengthier and more tedious processes. Automation can help you perform this process more efficiently. Automatic code review works similarly to manual review except it is done using tools that integrate with development environments. These tools can check for styling, security, duplication, complexity and code coverage, and can auto-suggest corrections. Some popular tools for this automation include Codebeat, Code climate and Codacy.
Automating File Synchronization and File Uploads
Many DevOps and development teams use the public cloud for quickly spinning up development and test environments. However, what happens when the production environment, or other critical resources used in the dev/test process, are deployed on-premises? Having a fast, automated and reliable way to synchronize files between the on-premise data center and the cloud can save time and headaches.
There are a few approaches to synchronize files:
Scripting file uploads and downloads. The most basic method is to use shell scripts and FTP or SFTP to upload and download files between local and cloud environments. However, this can be fragile, unreliable and difficult to scale.
Using APIs of cloud storage services. You can move data to and from the cloud using cloud storage APIs, such as the Amazon S3 API, the Box API or specialized hosting services such as Cloudinary.
Hybrid cloud. The ultimate solution is to create a hybrid cloud architecture where applications, developers and users view the local environment and the public cloud as one unit, and data is synchronized transparently in the background.
Collaboration Tools for DevOps Teams
There are a number of collaborative tools that teams can use to further boost gains from automation. These tools can help bridge gaps in automation and processes and ensure smooth workflows.
Slack: a chat tool that DevOps teams can integrate with automation tooling. It includes features for segregating discussions by topic, team or purpose; uploading shared files and documents; and initiating or receiving alerts from automated processes via integrations.
Jira: a tool that enables you to create and assign tasks. It includes features for scrum and kanban methodologies, unified reporting and backlog tracking. You can integrate it with many common DevOps tools, such as Jenkins.
Trello: a cloud-based Kanban board tool. It enables you to create project boards that can be shared across teams to track project progress. Through integrations, you can automate the updating of cards or initiate processes when cards are manually moved.
Asana: another cloud-based Kanban tool. Like Trello, it enables you to track and collaborate on projects across a team. Typically, when teams use tools such as Asana, they create multiple boards for different project aspects. These boards can then be viewed individually or from a central dashboard.
Conclusion
Hopefully, this article helped you figure out how to leverage automation for improved efficiency. There are many automation options for DevOps, including automated regulatory compliance, automated infrastructure, automated code review and automated file synchronization.
For DevOps project management, you can use collaboration tools such as Slack, Jira, Trello and Asana. Remember to make sure that any tool you introduce can be simply and easily integrated into your current environment. The tools of your choice also need to fit the skillset of all collaborators. For ease of use, keep your tooling ecosystem simple and minimalistic.
Ever since Mark Zuckerburg uttered the phrase “move fast and break things,” it has become the motto of many development teams. Companies wanting to be the next unicorn decided this must be the way to operate. The race was on to release more, ship faster, never stop. If moving slowly and methodically wasn’t working, doing more had to be the key to success.
These companies would cherry-pick statistics from reports such as the Accelerate: State of DevOps Report. The 2019 report showed elite companies have 46 times more frequent code deployments than low-performing teams and a 2,555 times faster lead time to move from code commit to deploy to support their initiatives to move faster.
The problem is moving fast doesn’t work across industries or for all teams. To effectively move fast, you need processes in place to support the velocity. The consequences of moving too fast and not being able to fix things when they break are high.
How We Got Here
What has gotten us to the point where we are moving too fast? In short, we have. How do you feel when it takes months or a week for a PR to be resolved compared to hours or days? As consumers and end-users of software, our expectations are continually rising. We have to ship quickly because that is what we as consumers expect. As customers, we are pushing companies, which in turn push their employees to meet the increasing expectations.
What are the consequences when you try to move fast and not just break things, but fail?
It takes longer to resolve incidents.
You lose customer confidence and sales.
Employees burnout and you have a high turnover rate.
Let’s go back to the stats from the Accelerate: State of DevOps Report. Yes, elite teams ship faster. But, their changes are 1/7 as likely to fail and they recover from incidents 2,604 times faster than low-performing teams. It’s not just about moving fast and breaking things; it is about having the right systems and processes in place to support this way of working.
Setting Yourself Up for Success
You need two things to effectively move fast: a culture of psychological safety and smart investments in tooling. Employees need to feel empowered to speak up if things are moving too fast, if they are concerned about why a feature is being built and to identify gaps in the processes. They need to feel they won’t be blamed when something breaks. Building this requires empathy, open communication and teamwork. This psychological safety is the foundation of being able to move quickly and quickly recover when things break.
Next up is selecting the right tooling and processes. Invest in tools that make things easier. Tools should be useful, usable and change the underlying problems, not create more.
Think about the tools in place to quickly resolve incidents when something fails:
Observability and monitoring tools to identify and notify when things go wrong.
Incident management tools to route, track and escalate issues.
Feature management tools to enable circuit breakers and load shedding to turn off features quickly.
The culture and tools are part of the equation; the final piece is having the right processes in place to effectively use the tools and support the people.
What are some processes you can implement to enable safety at speed?
Schedule chaos days to understand how things break and know how to fix them.
Run experiments to gather feedback and ensure features are moving in the right direction before a release.
You should attempt to move fast, you should try to break things—but only when you have the right protections and processes in place. Using a combination of the right tools and processes, you can deliver more value faster without sacrificing quality or your employees’ health.
Companies are looking to reduce cost, create efficiency and improve productivity of all internal and external customer services. In many organizations, different departments are using individual tools to provide their customers with the services they need. They can work in silos, can provide inadequate quality of service and not to mention that the portfolio of different tools can be quite costly.
Enterprise Services Management (ESM) is a popular approach to implementing services within the organization. Departments such as human resources (HR), operations and marketing are seeing the value of Information Technology Service Management (ITSM) processes, and companies are looking to repeat that same value across the business. ESM allows all departments in the organization the opportunity to standardize tools and processes across all of their services departments. This standardization of tools and processes can create transparency, can improve the customer experience and in the end can reduce overall cost.
There are quite few tools that can be used to support the implementation of ESM. Two components of an effective ESM implementation include a shared service desk and a knowledge base.
The shared service desk encourages the standardization of tools, and even paves the way for the alignment of processes. Departments should find tools that can be scaled up from just ITSM to support requirements across different service departments. There are quite a few applications available to companies for a shared service desk.
In order to promote adoption, organizations must consider the ease of usability for both customers and customer service providers. Atlassian has two applications, Jira Service Desk (JSD) and Confluence, that together provide companies their shared service desk and knowledge base components of their ESM solution.
JSD can be used as the foundation of an organization’s ESM implementation. Having JSD as the standardized service desk provides customers with a single customizable portal for all requests across the business. Unlike Jira Software and Jira Core, JSD licensed users are called agents. Companies only pay for agent licenses and do not pay for their customers.
Below are just some of the features that are available with JSD:
A portal that can organize request types for customers. This provides them one place to submit all of their requests across the business.
Customizable workflows that include features such as custom statuses, conditions and post-functions.
Queues that provide the ability for agents to monitor and manage requests.
Service Level Agreements (SLAs) that help set time frames for agents to complete a certain step such as responding to the customer and even resolving the request.
The ability to automate certain workflow steps.
A plethora of built-in reports, to include one that shows overall customer feedback satisfaction.
The next component is a knowledge-base. Why is a knowledge base valuable to both customers and agents? Confluence is a wiki that helps teams organize and share information. A well configured knowledge base can empower the customer to answer the questions they have without submitting a request. This can reduce the time agents spend on common requests.
Confluence has the ability to create a knowledge base, and seamlessly integrate it with JSD. Confluence is organized by pages, which are structured in a series of parent-child relationships—in the end form it’s called a page tree. To add/edit articles in the knowledge base, the person will require a Confluence user license. However, any customer can read the articles in a knowledge base without a license.
Below are just a few of the available features with a Confluence knowledge base:
Built-in templates for how-to and troubleshooting articles.
Page labels that help serve as keywords for customers and service desk agents when searching for knowledge base articles.
Below is a process flow for customers submitting a request in a typical ESM implementation using JSD and Confluence:
User launches portal in web browser.
In the portal, if a knowledge base is configured, the user can start typing keywords to search for articles that answer their question.
If the user does not find the answer to their question in the knowledge base, they can navigate within the portal to the request type they wish to submit. The request types can be grouped by department.
User completes the request form. Fields can be custom or out of the box. They can also be required or optional.
Form is submitted and it creates an issue in JSD.
The issue is added to one or more agent queues. Agents can also receive notifications in email, and third party applications such as Slack, Opsgenie or PagerDuty.
Agent communicates with the customer via comments in the Jira issue, and the customer communicates with agents via the customer request interface.
Agent works on request in until its resolution.
In summary, ESM is continuing to improve value in organizations for many reasons. One part of a successful implementation of ESM is which tools are selected for customers and customer service providers.
