Applying the lessons learned from the NCAA tournament to DevOps in your organization.
‘Tis the season for filling out brackets, secretly checking your favorite team’s livestream at work and watching your ranking rise and fall in the office pool.
Unless you’re this guy, your bracket is already busted. However, there’s always hope for next year, especially if you pay attention to five key indicators that experts say predict the success of teams in the NCAA championship.
But you don’t have to wait until 2020 to put these tips into action. In fact, carefully constructing a March Madness bracket can actually teach you a lot about DevOps.
The following five tips can be applied to your next bracket, as well as your software development team:
Don’t Rely on Offense Alone
A great offense is key to scoring, but the gap between offensive and defensive efficiency can make all the difference when it comes to a team’s chance at the championship. Over the last 17 years, only one national champion didn’t finish in the top 20 for both offensive and defensive efficiency. Similarly, software teams have to rely on multiple team members including the programmers focusing on new features and fast plays, as well as the QA and operations teams ensuring that there are measures of testing and monitoring in place, so those same features aren’t released with bugs and breakages. To be successful, you need to aim for a balance of speed and quality. In DevOps, your efforts will fall short if you’re only thinking about your offensive strategy while underestimating the importance of strategic defensive plays.
Coaching is Crucial
Coaching experience has become a strong predictor of future success, as 15 of the last 17 NCAA title champions were led by a coach who had been to the Final Four previously. Similarly, leadership and management in DevOps and the transition to DevOps is paramount to creating an environment that is supportive of the necessary changes. In fact, according to a Forbes Insights and PMI survey, 85 percent of respondents said that change management is critical to their success in times of disruption. As teams attempt to speed up their processes to meet consumer demands, it’s evident that leadership is going to be a defining factor of the success of the team. Additionally, amid a cultural shift, management needs to have the right mindset to get the entire team on board, adopting new tools and practices. Just as coaching influences college basketball, experience, skill and vision all come together for transforming a team and creating a culture of DevOps.
Expect Upsets
Upsets happen—that’s the beauty of March Madness! While teams are seeded to indicate the likelihood of success in the NCAA tournament, you might think that it’s always best to pick the highest seed. But according to the NCAA, you should be aiming for around 16 upsets in your bracket. Just ask anyone who had UVA in their Final Four last year, when the No. 1 seeded team lost to 16-seed UMBC, how important it is to expect an upset. Sometimes, all your systems are perfectly in place and everything is performing as it should, and something will still break. What’s more important than aiming for perfect software delivery is having the processes in place to patch bugs, handle downtime and fix errors when they inevitably occur.
Teamwork Will Tell You Everything
There’s always talk of the star players, but success comes down to much more than one person’s free throw percentage, shooting efficiency and steal rates. Most of the statistics you look at to build your bracket revolve around teamwork—the team’s strength of schedule, the team’s winning streak, the team’s loss margin, even the measurement of explosiveness and competitiveness. None of these points can be attributed to one person; they change from season to season, and they’re all about how the entire team works together. Selection Sunday is needed every year to seed the teams because performance changes every year based on the team dynamic. Similarly, your organization will not be successful in DevOps if there is not a focus on communication, collaboration and teamwork.
The Absence of Key Players Will Trip You Up
While you can’t depend on one star player to determine the outcome of an entire team, you’ll also run into trouble if key players are out for the season. Just think: You probably wouldn’t pick Duke to win as quickly without Zion Williamson. Just the same, when there are key teams and team members missing or not committed to a changing culture, it will hinder others. There are various roles that every organization needs to succeed in DevOps, and this requires everyone to be on the same page whether you’re in development, operations, QA or are a business stakeholder. People are one of the most important parts of the transition to DevOps; if the entire team doesn’t show up, new technology and approaches won’t be able to make up for it.
There’s a strategy to everything, and it just so happens that your approach to DevOps may be similar to your approach to filling out your bracket.
By following these five pieces of advice, your software team will be more prepared to win it all when it comes to attaining a faster delivery of high-quality products.
I attended Adobe Summit 2019 to research the intersection of DevOps and marketing. Below are insights from my interviews with leading marketing technology experts.
Is DevOps making its way into marketing? In a short answer, a soft “Yes.”
I recently attended the Adobe Summit, held March 26-28 in Las Vegas. This year emphasized digital customer experiences, and I was curious to take a peek into this world of marketing tech to see if DevOps was having any impact.
Many of the people I talked to described how marketing technology is adopting a more agile, DevOps-inspired mindset. But is marketing actually driving product change? While Adobe and proponents would like to have us think so, some are not as sure.
At Adobe Summit, I had some eye-opening meetings with professionals invested in digital marketing, retail and analytics services, most of which are using Adobe products in some form. In this article, we’ll highlight what they had to say on the intersection of DevOps and marketing.
What is the Role of DevOps in Marketing?
The need to break down data silos was a common theme among keynotes, sessions and throughout my meetings at Adobe Summit.
When large digital marketing agencies take on clients, for example, a common disability they find is a disparate and dysfunctional customer data storage system. In our meeting, Alex Kelleher, managing director at Deloitte Digital, noted, “Data needs to be available, and integratable. That is the first thing we typically fix for our clients—we’ll fix the data in silos, get it in the same place, and usually simplify it.”
Deloitte Digital’s process involves three D’s: first, they consolidate data silos, then build data-driven decisions, then deliver agile products. In doing so, Kelleher is seeing more and more developer practices making their way into marketing and sales.
“We’re seeing CMOs manage their teams as agile teams, recruiting agile and scrum masters,” he said. “That’s very cool for CMOs to be involved in … those worlds colliding is super exciting.”
Is DevOps Eroding Traditional Boundaries?
DevOps principles encourage shared knowledge and open communication between teams. Now, it appears such ideas are affecting how marketing technologists architect their teams and delivery cycles.
Rachel Lane, solution principal customer experience at Medallia, sees a trifecta of forces working in tandem. “Development, Ops, and Marketing must work together,” she said. “If one of those doesn’t link up, then we see extended lead time to launch, and it can become problematic.”
Medallia’s goal is to meet customers where they are to gather actionable feedback through push notifications, surveys, embeddable surveys, Net Promoter Score (NPS) systems and other means. Engrossed in this world of customer feedback, Lane reminded us: “You should never ask a question that you already know the answer to.”
Unfortunately, this still happens often. User data is often locked in silos and if multiple teams (sales, marketing, support engineers, etc.) are using separate user data repositories, customer interaction can suffer. Thus, user conversation data must be de-siloed and unified.
For Lane, having tight customer experience-driven feedback is critical for reiterating the overall product. However, customers typically hate filling out surveys. To decrease friction, she foresees more passive voice-driven feedback through home AIs.
Rearchitecting the Digital Footprint for Agility
By now it’s evident that unclear data initiatives and messy data storage can hinder digital transformation. So, what are organizations doing to de-silo and open up data?
Anheuser-Busch (AB) is a huge beer corporation, overseeing brands including Budweiser, Busch, Elysian and many others. Each has unique online eCommerce storefronts to sell ancillary swag, such as T-shirts, drinkware and other products.
With public-facing sites for hundreds of brands, maintaining data standardization across its product lists was a nightmare. Disparate data structures can also inhibit directing change from within, slowing corporate-led growth.
John Faviano, director of demand and integrated marketing technology at Anheuser-Busch, described how AB solved the issue by creating a consistent data structure from which all online stores can pull content from.
“We’ve standardized the tech stack in the last three years to enable the business to run more efficient … You have to think from a platform perspective, not a single siloed technology,” he said.
AB’s web APIs now grant incredible scalability, as the content is now delivered agnostic of client or brand. AB brands retain independent facades yet are fueled by a unified content storage and delivery process. “Our API strategy is a build-once-and-scale mechanism,” Faviano said.
Digitization with IoT and AI
Sreedhar Bhagavatheeswaran, SVP and global head of digital business at Mindtree, believes that every part of the enterprise needs to be digitized. He sees a wealth of untapped data that enterprises can leverage to transform user experiences.
Having built digital presences for big-name consumer brands including Marriott, P&G and Kellogg’s, Mindtree understands the advantages of using a DevOps approach for software cycles. Though it may require a cultural change, “The probability of project success in a DevOps environment is much higher than in a non-DevOps environment,” Bhagavatheeswaran said.
Release automation is integral to Mindtree’s process. Coding checks and CI tools such as Jenkins bring quick releases, enabling business teams and clients to see the impact on a daily basis. They also privilege API-fueled microservices designs for increased agility.
“From an agile program management perspective it gets challenging, but that is the nature of the beast,” he noted.
Bhagavatheeswaran is excited for the potential IoT has to evolve industrial, business and consumer-facing touchpoints. For example, industrial engineers could conduct remote servicing using digital twins of real physical equipment. He also described developing mobile IoT apps for his clients: Push notifications triggered by removing caps from makeup bottles, for example, could empower consumers with advice on how to apply makeup correctly.
To sum it up, Bhagavatheeswaran described our current paradigm with a simple, powerful sentiment: “The experience is at the confluence of edge, humanity and intelligence.”
Approaching the Developer Experience
But digital transformation doesn’t stop with open data, APIs and IoT. Developer experience (DX) has become an important factor in maturing countless digital services.
Jason Woosley, VP of commerce product and platform at Adobe, founded the Adobe-acquired Magento, which began as an open source project on GitHub, welcoming pull requests to alter product features (with the proper vetting in place, of course).
By investing in open source and developer communities, Magento over time reached a critical mass, democratizing how developers build online storefronts.
Woosley estimated that 50 percent of Magento code was built by third-party developers. One such feature is multi-source inventory, which, he said, accounts for 70 percent of the Magento code base. Naturally, he has a deep appreciation for the power of developer communities.
“You can’t buy a developer community. You can’t steer or create a culture,” Woosley said. “Code custodians are actually participants, and to deserve that role DX needs to be delightful and empowered.”
To improve the developer experience, Magento has hosted countless events, increased developer support staff, annotated its APIs, adopted GraphQL for extensibility, invested in optimizing developer portals and more. With the inclusion of Magento in Adobe Experience Cloud, more capital is available to further DX enhancements—something Woosley is excited about.
Wednesday March 27, 2019 in Las Vegas. (Jeff Bottari/AP Images for Adobe)
DevOps is Kicking Martech to Innovate
Deloitte Digital’s Kelleher noted that “nowadays, your competitors are any digitally active application,” regardless of whether they’re even in the same industry.
This means that a consumer will judge a mobile digital experience with an airline with the same scrutiny as calling an Uber or making a PayPal transfer. Users hold the same lofty digital expectations from any business, forcing us all to adapt dramatically.
Fueled by the relentless pressure from users, marketing technologies are adopting DevOps principles to improve their offerings in a few ways:
Continuous releases: Martech uses DevOps strategies to release quickly. User-facing mobile app release cycles, for example, routinely adopt CI/CD.
De-siloing: User data and consumer conversation information are being distributed with greater alacrity across enterprises, improving end UX.
Open data initiatives: With web APIs, new platform-agnostic content distribution architectures have emerged. Development procedures are standardized across an enterprise, quickening the release cycle.
Cloud architecture: By adopting cloud-based management tools, martech is improving the asset management condition of supporting many user-facing touchpoints.
Developer experience: By embracing open source and supporting developer community, leading e-commerce groups are improving their offerings.
While marketing is critical to the whole, it may not be the No. 1 business driver. When I asked Bhagavatheeswaran whether marketing was really driving the creation of new tools, he responded: “Is marketing driving the tools? Are they influencing? Not quite yet. However, it has the ability to influence the developer’s quality. Probably not their job.”
Even if marketing is not directly influencing product development, we’re still seeing DevOps seep into traditionally non-technical environments, which is exciting.
It was eye-opening to enter the world of marketing technology to see firsthand how these institutions—such as Ansira, a 100-year-old company—are using agile means to streamline digital transformation initiatives.
With an emphasis on both creating and managing quality digital customer experiences, Adobe Summit 2019 shed light on many unique strategies being undertaken in the realm of martech.
Whether it’s leading the development of user-facing apps, overseeing expansive brand catalogs, using a cloud-based single source of truth for content management or building developer communities to reap huge R&D benefits, the intersection of marketing and technology has never required more strategic action than it does now.
Completing a large-scale agile transition can seem intimidating for any business. Agile pushes teams to change their cultural expectations and work processes—a combination that is tough on any work environment. Larger organizations, however, often face an especially daunting migration.
The good news is that businesses don’t have to face these migrations alone. In my work, I’ve overseen plenty of examples of successful agile projects. Those efforts have taught me many lessons—with one major project standing out.
An Agile Migration at a Glance
I recently worked with a large automotive company to help it scale out to a more sophisticated agile development scheme. We applied a customized Scaled Agile Framework (SAFe) to the project. In doing so, we established a development environment with:
15 scrum groups divided under four release trains.
A product feature team configuration to define user responsibilities.
Two-week sprint cycles.
A quarterly innovation and planning (IP) sprint.
A transition from VersionOne to Rally.
Weekly production deadlines.
After six months, the company had a continuous delivery (CD) pipeline in place and we had laid the groundwork for a successful project. Of course, plenty of bumps arose along the road to a solid agile environment. Here are five lessons we learned during the project:
Don’t Allow for Missed Connections Between Scrum-to-Scrum Teams
We established a feature team setup for this project. In the setup, teams worked on specific feature sets instead of simply dividing components of the software and hoping it all worked when put together.
The initial plan was to have quick sprints and an emphasis on features that would allow for relatively simple dependency management. In action, however, different understandings of features between groups led to some challenges, including issues linking feature teams and eventual defects after integration. This challenge reinforced the importance of a few key best practices, including:
The vital role of a “Scrum of Scrums” team featuring representatives from each scrum to provide cross-team collaboration and ensure work is coordinated.
The need to build out retrospective cross teams to minimize dependencies and identify the universal issues within the agile system.
The necessity of end-to-end testing that is clearly set forth in the Definition of Done (DoD) project framework. Creating clear DoD parameters can help teams ensure they minimize redundant work while avoiding mismatched data within the QA environment when compared to production.
Continuously Inspect Sprint Expectations and Right-Size Project Guidelines
Throughout the project, we found that, in some instances, teams struggled to identify the best velocity for sprints, even after four or five iterations. There was a lack of transparency into whether timelines were actually working because formal discussions around scrum velocity weren’t taking place. This resulted in technical debt adding up over time and incorrect ideas about what constitutes a completed project.
Struggles to identify the right speed for scrum sprints created instability. We learned to counter this problem by formalizing scrum event planning so teams could identify the right velocity for their tasks and recognize times when they may need to adjust how they were working in light of shifting project demands. This included honestly assessing technical debt and setting timelines for dealing with it.
Identify When ‘Done’ Doesn’t Really Mean Done
A great deal of effort goes into identifying the DoD for a project. However, teams can easily struggle to pin down the Definition of Ready (DoR) for backlogged items that arise as the result of technical work. This situation can spiral as small items are left incomplete over multiple sprints until, near the end of the project timeline, testing and similar practices get less attention because everybody is scrambling to complete work. A few ways we overcame this issue included:
Using the INVEST criteria to prioritize tasks when trying to identify DoR. This is particularly important as teams that neglect small issues of technical debt risk falling into waterfall habits toward the end of project cycles.
Trying to minimize how many work-in-progress items we left unresolved at any time to avoid situations where dev teams are spending more time on backlog items than active sprint work.
Creating visualizations of the shared scrum space for better coordination and monitoring across teams.
Establishing consistent analysis and updates to the DoD to better reflect real results. This was best accomplished during the sprint retrospective event.
Don’t Neglect Training
Agile is all about getting projects moving quickly and eliminating waste. In that vein, many organizations will try to reduce training and spend a couple of weeks teaching workers about agile and expecting them to mature through their experiences on scrum teams.
In action, scrums need an opportunity to go through storming mode together to develop their agile skill sets, but companies typically don’t set aside time for that type of training. Businesses must establish realistic expectations in terms of training, particularly for cross-functional and self-organizing groups, as these users need a deep understanding of best practices to work well together. Employees need time to adapt to change. Businesses that want to scale agile effectively must establish their core values, reduce direct accountability within new teams that feature interdependencies and, in general, be patient with employees as they adapt.
Within this transition to agile, it is also important to train users on how to work effectively as a team. Technical skills and process education is key, but those capabilities can fall flat if employees are unable to work well together. For example, the landmark book, “5 Dysfunctions of a Team,” highlights a variety of typical challenges that teams face, including lack of trust or unwillingness to face up to conflict. Businesses need to train workers to counter these types of issues.
Leverage Efficiency Tools, but Not with Excessive Rigidity
In this project, we used Rally, an enterprise-class platform built to help businesses scale agile teams. Even in Rally, there are some limitations to how much the technology can support collaboration between teams and identify project dependencies.
In practice, no single tool will be an agile silver bullet. Instead of expecting a platform to solve your problems, consider adopting practices that make sense for your situation, such as tracking dependencies on a whiteboard. Within this environment, it is vital that businesses also clearly define and manage their development and release processes through ongoing training that establishes a culture of transparency.
With serverless, you delegate the responsibility of running your infrastructure to a platform provider as much as possible. This frees your engineers to focus on building what your customers want from you—the features that differentiate your business from your competitors’. For this philosophy to work, however, the platform needs to not only give you the tools to build those features, but also deliver the performance that will keep engineers satisfied.
Yes, services such as AWS Lambda are powerful, but they have a number of well-documented limitations that make them unsuitable for some workloads. These include:
Cold starts and high latency make them unsuitable for real-time applications that require consistent and millisecond-level response times.
The pay-per-invocation model makes them costly in high throughput scenarios.
The event-driven model, coupled with a max execution time or data size restrictions, makes them unsuitable for long-running tasks or heavy data or AI processing.
They are limited to triggers and event sources that are specific to the cloud provider.
Enter Nuclio, an open source serverless platform that is built on top of Kubernetes and comes in both managed platform-as-a-service (PaaS) and self-hosted flavors. In this post, we will compare Nuclio with AWS Lambda, see how Nuclio addresses the above limitations and explore the new use cases Nuclio is unlocking, such as:
High throughput data processing pipelines or ETL.
Serving machine learning models in real time.
Real-time applications such as multiplayer games.
Long-running jobs and services.
Nuclio vs. AWS Lambda
Concurrency
One of the biggest shifts from traditional application development to AWS Lambda is how concurrency is managed. An Express.js web application running in a container/VM can handle multiple requests concurrently. In other words, your application manages its own concurrency. You scale the application by increasing the number of concurrent requests it can handle (scaling up) and then increasing the number of containers (scaling out).
Figure 1: Traditional applications scale up the currency within the application, then scale out the number of nodes running the application.
With AWS Lambda, concurrency is managed by the platform, and a concurrent execution would process only one request at a time—much like an actor in the actor model, which would process one message at a time. The application can scale out by increasing the number of concurrent executions of the function.
Lambda’s concurrency model has its advantages:
It simplifies application development. Concurrency is a constant source of bugs and performance issues, as developers struggle with writing highly concurrent applications.
It allows you to price each invocation individually because you don’t have resource contention from handling concurrent requests. This enables the pay-per-use pricing model and is one of the cornerstones of findev.
Still, Lambda also has some disadvantages:
You can’t make use of idle CPU cycles when a function is waiting on IO. Since most functions are IO-heavy, this results in significant inefficiencies.
It requires more scaling, which means more cold starts. To handle X concurrent requests, you need X concurrent executions, which equates to X cold starts. This makes it nearly impossible to achieve predictable performance.
Nuclio, on the other hand, can scale up as well as out. A function processor (analogous to a container) can host multiple function workers. Each worker is then able to process one message at a time. This system supports concurrency within the same processor, and then autoscales the number of replicas of the processor based on load.
Figure 2: The architecture of a Nuclio function.
Another interesting difference between Lambda and Nuclio is that Nuclio lets you specify both the minimum and maximum number of replicas. And as an aside, Nuclio also supports GPUs.
Figure 3: Nuclio lets you configure both the minimum and maximum number of replicas.
With Lambda, you can configure a reserved concurrency for a function, which (counterintuitively) sets its max concurrent executions. But there is no way to tell the system to always keep a certain number of concurrent executions running at all times. The system always scales to zero when there is no traffic—behavior that is highly undesirable for systems that experience regular spikes in traffic.
For example, my employer, DAZN, is in the sports streaming business. We see huge spikes in traffic all the time, as millions of users flood in seconds before a sporting event starts.
Figure 4: Sports streaming platforms, such as DAZN, experience huge spikes in traffic just before a sporting event kicks off.
Without the ability to configure the minimum number of concurrent executions, these spikes result in large numbers of cold starts. Also, in these cases, Lambda has to scale out the number of concurrent executions quickly to meet the surge in demand. Here, we also run into the 500/minute limit on how quickly Lambda is able to scale out. As such, we are currently not able to use Lambda on the critical path of our system, which has to shoulder these spikes.
With Nuclio, you can programmatically update the minimum replica count prior to the event so that when the spikes come, you don’t have to worry about hitting scaling limits or enduring the performance hit from cold starts. You can also tell Nuclio to scale to zero immediately via API calls, which saves resources.
Figure 5: Adjusting the minimum number of replicas enables you to deal with predictable spikes in traffic.
Timeout
Another major difference between Lambda and Nuclio is how timeout is handled. With Lambda, an invocation can run for up to 15 minutes. While it’s possible for you to use recursive functions or step functions to extend this limit, both approaches have their own problems. As such, Lambda functions are great for event-driven architectures and performing short, ephemeral tasks.
With Nuclio, there is no max execution time. The containers can keep on running, which in turn allows you to go beyond the constraints of the event-driven model. You can now turn a function into a long-running service, which unlocks some interesting use cases such as long-running ETL jobs and training machine learning (ML) models.
Caching State Between Invocations
Both Lambda and Nuclio functions accept an event and context during an invocation.
Figure 6: Both Nuclio and Lambda functions accept an invocation event and context as arguments.
With Lambda, the context object is ephemeral and does not persist between invocations. If you want to persist data between invocations (e.g. static configurations, database connections), then you need to declare them as global variables outside of the function handler.
With Nuclio, the execution context itself is persisted between invocations and can be used to cache state. The context object also includes a built-in logger, which supports structured logging with JSON and four log levels: DEBUG, INFO, WARN and ERROR.
You can configure the default log level for a function and can even override this default log level per invocation—which is very useful for debugging. You also have the ability to export your logs to external services such as Elasticsearch.
Figure 7: With Nuclio, you can select the default log level for every function.Figure 8: You can also override the default log level for an invocation.
In addition, there are hooks for performing context initialization, which is called before the first invocation on the function. This allows you to perform initialization logic before the container is put into active use and removes the dreaded cold start problem that Lambda suffers from.
Data Volumes and Persistent Data Connections
With Lambda, functions only run when they are triggered by events. Furthermore, concurrent executions are garbage-collected when they have been idle for a few minutes. This behavior makes life difficult when you are working with relational database management systems (RDBMS) and other systems that require persistent connections. Indeed, a set of guidelines has been developed to help you avoid the many pitfalls of using Lambda with RDBMS. Furthermore, Lambda doesn’t allow you to use persistent data in standard file system mounts, which forces you to copy to/from object storage before working on large files such as images, logs, ML models, etc.
With Nuclio, however, you can use the context object to maintain persistent connections to databases. Since the context is maintained at the processor level, you get better reuse, as they are shared across invocations. You can also take care of other aspects of data-fetching with data bindings, including batching and caching, which helps improve IO performance of the application. Additionally, you can mount volumes to functions, which is useful for working with ML models or Tensorflow, and you can mount Kubernetes secrets as volumes. Indeed, Nuclio supports all of the volume types that Kubernetes supports.
Runtimes
Both Lambda and Nuclio support popular languages such as Go, Node.js, Python, .Net Core, Java and Ruby. Also, both platforms offer a way for you to customize the execution runtime.
With Lambda, you can create a custom runtime and distribute it through AWS Lambda Layers. This lets you introduce additional language runtimes that are not natively supported by the Lambda platform. Several vendors have published runtimes for PHP, Rust, Erlang and Elixir, to name a few.
With Nuclio, you can run functions on your own Docker image (see Figure 9), which can come from a private image repository. This allows you to tailor the execution environment itself.
You can also support additional language runtimes through a Shell function, which allows you to handle invocation events with any executable binary. See this example for more details.
Figure 9: Nuclio lets you run functions on top of your own Docker image, which can come from a private image repository.
Nuclio ships with 13 triggers, including cron, HTTP, Kafka, Kinesis and RabbitMQ. Since Nuclio is open source, you can also write your own trigger for services that you want to integrate with and leverage other people’s contributions. The HTTP trigger gives you an easy way to integrate Nuclio with other event sources that support HTTP as target, such as SNS. Also, since Nuclio supports the CNCF CloudEvents standard, it can arguably support many more event sources that are CloudEvents-compliant.
Nuclio triggers are all normalized to the same Event object. This removes the need to understand the specific event signature for each event source, which is often confusing when working with Lambda. It also makes it easy to switch a function between different triggers.
Built-In HTTP Trigger
With Lambda, you need to use API Gateway to create an HTTP endpoint for your functions. API Gateway is a feature-rich service, but it’s also complicated and often costs more to run than the Lambda invocations themselves. It also adds another source of latency to your API, which, at the minimum, is around 5ms to 10ms, and it can overhead spike to more than 100ms. This cost and latency overhead make it unsuitable for applications with high throughput or hard real-time requirements.
With Nuclio, every function gets a private HTTP interface by default. To expose the endpoint publicly, you need to specify an HTTP trigger similar to API Gateway. However, unlike API Gateway, this HTTP trigger does not incur extra costs and has minimal latency overhead.
Figure 10: With Nuclio, every function gets a private HTTP interface by default.
Unlocking New Use Cases with Nuclio
As you can see from our comparison, Nuclio differs from Lambda in a number of important areas, such as its concurrency model and that it has no max execution time. This opens the door to a whole range of use cases. Let’s take a moment to look at a few.
High-Throughput Data Processing Pipelines or APIs
For a high-throughput API, the cost of both API Gateway and Lambda is drastically higher than an equivalent application running in containers. This cost discrepancy has lead many to rewrite their applications.
Nuclio’s concurrency model makes more efficient use of available resources, which significantly reduces operational cost when running at scale. Functions have built-in HTTP interfaces so you also don’t need to pay for an expensive API Gateway service.
The ability to mount a volume to your function also lets you read and write data to/from a mounted volume at high speed and enables building stateful applications. Again, you can’t do this with Lambda today, as it doesn’t allow you to attach Amazon Elastic File System (Amazon EFS) volumes to functions.
These features make it economically feasible to run high-throughput and high-performance APIs on Nuclio functions. The same can also be said about high-throughput data processing pipelines that have to process multiple terabytes of data per hour.
APIs with Predictable Spikes in Traffic
Nuclio gives you the ability to configure a minimum number of replicas. This allows systems that experience predictable spikes in traffic to reserve sufficient resources ahead of time and avoid degrading the user experience when the spikes happen. Examples include food ordering services such as Just Eat or Deliveroo or sports streaming services such as DAZN.
At the same time, Nuclio still lets you scale to zero by setting the minimum number of replicas to zero. It gives you the control to optimize for resource usage or latency, depending on the situation.
Real-Time Applications
Nuclio does not suffer from cold starts and is able to deliver consistent and sub-millisecond response times on invocations. This makes it a suitable solution for applications with a hard, real-time requirement such as multiplayer games and real-time bots.
Serving Machine Learning Models in Real Time
To serve ML models in real time, you need to have both strong and predictable API latency and the ability to load and work with ML models that often are large in size (GBs).
Nuclio lets you attach Kubernetes volumes to your functions, and there are no size limits on these volumes. Combined with the performance characteristics, it’s possible to implement these demanding workloads with Nuclio functions.
Nuclio also has native integration with Jupyter, and lets you automatically deploy Jupyter notebooks and ML models as Nuclio functions.
Long-Running Jobs and Services
Nuclio does not impose a max execution timeout on function invocations. This allows you to turn your functions into long-running services and perform long-running ETL jobs.
Nuclio’s init_context() hook lets you create long-running services, such as an application that constantly reads off a Twitter feed (e.g. loads the TwythonStreamer with the context, which is polling an external service, versus becoming triggered by an event).
Conclusion
As we discussed, Nuclio is one of the few open source solutions that are also business-viable. It has key architectural advantages for higher performance or data-driven applications, including:
Nuclio is cloud-agnostic. It can be used in multi-cloud/hybrid-cloud scenarios. You can also run Nuclio on a laptop using plain Docker, which makes debugging easier.
Nuclio’s concurrency model and the ability to mount file volumes lets you build high-performance APIs and high-throughput data processing pipelines.
Nuclio gives you greater control over the concurrency of your application, which makes it viable even for applications with very spiky traffic.
Nuclio’s execution contexts are persisted between invocations, and it doesn’t impose a max execution time on invocations. This allows you to create long-running stateful applications such as ETL jobs.
Nuclio lets you attach Kubernetes volumes to your functions and has no limitations on the size of the volume. This makes it possible for you to work with large ML models that often are GBs in size. Nuclio also has native integration with Jupyter and can automatically deploy your Jupyter notebooks and models as functions.
Nuclio provides a good out-of-the-box developer experience. It has a built-in logger with structured logging support, and you can easily export your logs to an external log aggregation service.
If you are looking for a serverless platform that is not tied to a specific cloud provider, Nuclio is worth a look.
Ongoing developments in technology have led businesses to look to the cloud for greater flexibility, scalability and processing power. The telecoms industry is no different. Under growing pressure to meet the demands of the internet of things (IoT) and 5G, service providers are increasingly adopting cloud and virtualization technologies such as network functions virtualization (NFV) and software-defined networking (SDN) to provide them with the capacity they need to manage the explosion in data traffic.
In an environment in which traditional telco revenue has been eroded by OTT (over-the-top, or IP-delivered) players, the commercial advantages offered by a telco cloud have never been more important. It’s hardly surprising then, that the global market is expected to grow at CAGR of 20 percent, reaching $29 billion within the next two years.
Don’t Believe the Hype
Despite the messages of benefits, however, operators have reservations, with many expressing concern that the hype around the promise of NFV and SDN is just that—hype.
During a panel discussion at the MPLS, SDN and NFV World Congress 2018 in Paris, representatives of Orange and Nokia, among others, raised questions over the current level of investment in the technology. SDN was described as “not really a new concept” and NFV as being a “bubble.”
It was additionally suggested that the benefits of virtualization weren’t particularly economical. Operators are becoming increasingly aware that the cost savings that NFV promises often are offset by the need to deploy entire racks of compute resources to handle processes that previously would have been supported by a single appliance. When you factor in the CPU and server requirements, along with the necessary power and physical rack space, the cost of delivering the same performance as a dedicated solution can be at least as expensive as a custom-designed alternative.
Performance and Power
Given the fundamental role that both SDN and NFV play in underpinning telco cloud, opinions such as those expressed in Paris are concerning—particularly when publicly voiced and apparently widely held. It’s clear then, that if they’re not already doing so, operators need to address these issues to realize the potential of telco cloud in the most cost-effective and efficient way possible. Indeed, time is of the essence, as the performance and scaling problems that operators face with generic NFV infrastructure are only set to get worse once 5G networks are fully implemented. The sheer volume and speed of data traffic through a 5G network, for example, will bring entirely new requirements in terms of scalability and performance.
Encouragingly, though, steps are being taken to tackle technical challenges around performance and power consumption, particularly with regard to generic hardware. By distributing workloads between x86 general purpose processors and software-reconfigurable, FPGA-based SMARTNICs that are optimized for virtualized environments or VNF re-architecture, operators are turning to hardware acceleration as a means of improving performance both now and in the future.
Look into the Cloud
The analyst forecast mentioned at the beginning of this article illustrates that, while discussions continue around the relative economic benefits of virtualization, there’s no denying that cloud-based network infrastructure is beginning to take root across the telecoms industry.
Increasingly we are seeing operators moving workloads on to virtualized or containerized infrastructure, for example, as they look to improve performance, reduce costs and hyperscale as required by their various network functions, applications and services.
What’s more, inspired by other sectors that have successfully leveraged cloud-native functionality, operators are embracing Agile and DevOps development practices. Telco cloud provides operators with the development agility they need to combine and re-combine existing functions that, when tested and proven for scale, can deliver entirely new network capabilities. With the ability to quickly bring innovative new ideas to market, operators now have a new avenue of revenue to explore.
The benefits extend into the wider ecosystem, too. Not only will an open multi-vendor platform running on open source software improve operational and cost efficiency, but by allowing software from multiple vendors to be more quickly integrated, it will enable the creation of innovative new network services and IT functions that, in turn, could led to new revenue streams.
And, of course, the new paradigm shift will improve the customer experience. Shortly after last year’s Mobile World Congress (MWC), for example, Verizon and Colt carried out the first demonstration of two-way, inter-carrier SDN orchestration, making near real-time bandwidth changes in each other’s production networks. The implications of this are significant, offering enterprise customers in particular flexibility on demand.
The 5G networks and the new generation of handsets, including foldable devices, dominated this year’s MWC. One look at the show’s agenda, however, shows just how important the cloud has become. And in meeting the demands of 5G and all it entails, its importance will only grow. It’s time, then, for operators to take a serious look into the telco cloud.
We’re attending Adobe Summit 2019 to research the intersection of DevOps and marketing. Follow along for more stories.
In a recent article, we described how DevOps is transforming retail from brick and mortar into an omnichannel “brick and click.” At Adobe Summit, we garnered more insights, discovering how other institutions are implementing an innovative convergence of physical and digital spaces.
The result is impacting all sectors, creating new hybrid environments within home tech, banking, apparel, and more. Let’s see which ones Adobe decided to highlight in its opening keynote to discover how companies of all types are reinventing themselves through digital transformation.
Best Buy: Evolving 1 Storefront into 3 Services
Best Buy is a prime example of digital transformation for retail. At Adobe Summit, Best Buy CEO Hubert Joly described how the company is reinventing the “New Blue” to enrich lives with the help of technology; a sense of purpose is a mobilizing factor that affects innovation.
For $200 a year, Best Buy in-home advisers will be your No. 1 on-call tech support. The company is also using AI to monitor seniors to trigger assistance when they are in need. Lastly, an app that compares features is bringing new in-store customer experiences.
Not solely a brick-and-mortar retail anymore, Best Buy is transforming with subscription services and online presences, bringing in multiple new touch points to stay competitive with eCommerce.
Best Buy CEO Hubert Joly sits down with Adobe CEO Shantanu Narayen March 26 in Las Vegas. (Jeff Bottari/AP Images for Adobe)
Intuit: Reinventing the SaaS Platform Model
Atticus Tysen, SVP & CIO at Intuit, described, how, over the years, Intuit has transformed its platform-based SaaS offering. Intuit is now utilizing ML and AI to improve its customer experience process. Doing so requires great data, as well as powerful data structures. As Atticus mentioned: “It all comes back to data…You need to monitor your data pipelines just like you monitor your offerings.”
According to Atticus, a core component of curating data infrastructure is democratizing it. Opening such data to all employees dismantles silos to increase the speed of IT. It’s this sort of horizontal thinking that fosters the collaboration digital transformation requires.
Atticus Tysen, SVP & CIO at Intuit talks with Cynthia Stoddard, SVP & CIO at Adobe, March 26 in Las Vegas. (Jeff Bottari/AP Images for Adobe)
Zumiez: New Zero-Code Methods to Build Online Shopping
Jennifer Small presented how the newly Adobe-owned Magento can be utilized to build and personalize shopping experiences. She walked through a theoretical Zumiez implementation, demonstrating how to make visual edits to develop cross-channel retail applications.
With the rise of eCommerce, traditional retailers such as Zumiez must create lean digital spaces to interact with end users. Not only must such environments be agile, but every point along the customer journey also must be individually personalized.
Online presences are adopting new tools such as AI-driven photo search, mobile A/B testing, user-driven optimization, responsive layouts, instant purchase and more. It’s only with the use of innovative tech that traditional retailers can stay relevant in a competitive landscape.
Foot Locker: AR-Driven Demo
David Nuescheler, Adobe Fellow & VP of Enterprise Technology at Adobe Systems, has been working hard in the lab using Adobe Sensei AI to take physical retail to new heights. In his demo featuring Foot Locker products, he painted an augmented reality that may be closer than we think for storefronts.
Using a catalog of cloud-aware assets, David demonstrated how a storefront could render innovative user-facing views in real-time. Using AR, his live demo rendered a custom shoe to appear on an empty shelf. He scanned and identified shoes on a product stand, and overlaid warehouse inventories on top of products in real-time.
Though demonstrated as a futuristic work-in-progress, such AR-infused digital experiences will likely arise in retail soon, adding a sense of magic to typical storefronts.
David Nuescheler, Adobe Fellow & VP of Enterprise Technology at Adobe, demonstrates some cool storefront AR March 26 in Las Vegas. (Jeff Bottari/AP Images for Adobe)
Chegg: From Textbooks to Online Tutoring
Textbook rental and academic platform Chegg also made an appearance at the Adobe Summit keynote. Chegg CEO Dan Rosensweig detailed the company’s initial fear when its IPO plummeted, and the frantic reorganization that followed. If any digital transformation story has a positive end in sight, it’s Chegg.
Now valued at $4.5 billion, Chegg was pressured to make a complete 180-degree pivot from shipping textbooks to embracing online subscription-based services. Though the company still ships about 5 million books a year, Chegg now has 1 million digital users. Academics from high school through to continuing education are leveraging Chegg’s tutoring and online study communities.
Chegg is deeply tapped into its consumer base, placing great emphasis on responding to “who [the customer] is, and not who they used to be.” For Chegg, using consumer analytics to architect the new digital business is a continuous, and necessary, commitment.
Chegg CEO Dan Rosensweig discusses with Adobe CEO Shantanu Narayen March 26 in Las Vegas. (Jeff Bottari/AP Images for Adobe)
Adobe: An Integrated, Impressive Services Catalog
A sure-fire case study in digital transformation is Adobe itself. Adobe CEO Shantanu Narayen kicked off the Adobe Summit 2019, its annual conference full of 17,000 tech-leaning CMOs and digital transformers in attendance.
Shantanu transparently outlined how, years ago, innovation in the Adobe product line had become stagnant. Compared to the infinite growth of content creation across the world, its static products weren’t doing the trick. This began to change rapidly with the introduction of subscription-based formats including Creative Cloud. Again, Adobe had found a foothold.
He demonstrated the company’s new Adobe Experience Platform, a holistic customer experience management platform. With many of the tools having been used as dog food at Adobe itself, the platform unites a large suite of applications dedicated to advancing the customer journey.
Discover, Try, Buy, Use, Renew
Discover, Try, Buy, Use, Renew. Adobe’s creed for customer experience management was reiterated many times at the Summit’s keynote. Such insights ring true in the agile transformation tactics taken by the businesses showcased above.
Adobe Summit—or, as Marketo’s Steve Lucas calls it, “the Woodstock of marketing”—showcased how successful agile companies placed customer experience as the driver for product design. In tandem, the future of retail holds an interesting future that meshes both traditional physical and digital experiences.
With customer experience now the No. 1 driver, should we place a “Mar” in front of the DevOps to create the triumvirate MarDevOps? The dogs are out.
Robot overlords are the stuff of science fiction fantasy. Today, with more teams implementing artificial intelligence (AI), DevOps teams need a hard, continuous look at reality. An AI overseer watching apps at work could make the difference between sadness and euphoria in your efforts.
We’re seeing AI misses more and more often. Facebook recently admitted its algorithms failed to stop uploads of a particularly heinous live-streamed video. Autonomous vehicles have struck cars and people. Jaywalkers in China have been misidentified and publicly shamed in error. It’s not for lack of effort in development. The adage “If it were easy, anyone could do it” applies.
A few weeks back, I was in a Twitter chat session on AI led by Kirk Borne, data scientist at Booz Allen Hamilton. The question came up of what organizations should consider when creating guidelines for use of data and bias-free AI. Here’s my response:
A4: DevOps teams should have someone whose role is AI oversight—actually watching what it’s doing and constantly testing/validating its findings #MITSMRChat
Most fails are due to fire-and-forget, wherein AI systems are trained, tested against training and turned loose. Even a well-designed AI system is subject to several problems:
Errors: This is where AI makes a factually incorrect decision. False positives and false negatives are in this category, along with miscategorization problems.
Gaps: There are situations in which AI understands conflicting options and is unable to choose. Then, there are situations in which the AI doesn’t recognize what it sees.
Bias: Maybe the system prefers green M&Ms or German shepherds because there was some subtle trend in the training data for “candy” or “dog.”
Ethics: This can be a higher level of bias, where preference is given based on age, gender or race. Sometimes it’s the classic no-win scenario in which both options are harmful.
An AI overseer guards against these types of problems in near real-time, every day, for as long as it takes to weed them out. Some problems are easier than others. An example of a more difficult problem came when autonomous vehicle researchers realized that not all traffic signs are brand new and well-lit. Shade, branches, wind, scratches, dings, bullet holes, stickers, graffiti and many more types of defects exist in the real world.
Increased Complexity
Inevitably, part of the solution the AI overseer leads is better scenario-planning and more training data. Retraining becomes a way of life and at some point, bigger data sets also lead to more complex implementations and another challenge: speed—after retraining to correct issues, the reloaded real-time classification engine runs like it’s stuck in molasses, producing correct results too late to be useful.
While the A system is running, a B version should be in development with new training and classifier boxes. For very large data sets, teams should consider designing a workload-optimized training server complex instead of relying on elastic cloud resources. This was behind NVIDIA’s recent acquisition of Mellanox—using InfiniBand for more bandwidth between GPU clusters in AI server complexes.
Where training systems often scale, real-time systems usually don’t. They are optimized for size and power consumption and can only accept so many additions. When a bottleneck emerges, it can kill the entire application. New generations of CPUs, GPUs and FPGAs keep pushing the envelope for designers tackling AI challenges.
Human-in-the-Loop
In many use cases, the job of the AI system is not to make every single decision autonomously. Instead, the system should make routine decisions and lead the AI overseer to look at exception cases. Directing humans quickly to areas needing attention is often more valuable than risking bad decisions. Human-in-the-loop is something DevOps teams should architect into systems more often.
This may all sound obvious, but it points out a big difference in developing AI versus developing code-based algorithms. If there’s a bug in code, you can debug it and find the offending lines of code to fix. But debugging AI is a lot more difficult. Digital twin implementations come into play using playback of real-work inputs to look at what happens inside the classifier black box. There are usually hints of problems developing before catastrophe strikes. Running data both good and bad can help spot issues.
Ideally, the AI overseer is a hybrid of a data scientist plus a systems architect. Look for someone who understands both data sets and hardware implementations, at least at a high level. They may have to call in other resources on the team for detailed investigations.
The last thing you want after all the hard work in developing a system is to have it run amok months or years later. It’s just Murphy’s Law. AI systems will do something entirely unexpected at the worst possible time. An AI overseer can help a DevOps team get ahead of AI problems.
Consumers expect to be able to do anything, anywhere and at any time in our digital world. They’ve grown accustomed to this level of speed and efficiency because business-to-consumer (B2C) companies have been delivering a frictionless customer experience for years. PayPal and Venmo are great examples of frictionless transactions and instant gratification through digital platforms: There is no need to coordinate, get approval or wait for someone else to execute the transaction. These companies ensure the most efficient payment option by allowing consumers to be autonomous.
The ease that we’ve come to expect in our consumer transactions is only now starting to become available in the enterprise. Business-to-business (B2B) buyers are the same people who participate in B2C transactions on their own time. They don’t become different people with different preferences when they go to work, so they are looking for the same quality of experience they’ve grown accustomed to in their everyday life. However, the enterprise software-as-a-service (SaaS) world is still evolving toward a model that doesn’t require contacting sales or negotiating a contract prior to delivering value. That said, there are still a few questions around how to manage customers, revenue streams and products that vendors need to answer.
Before Making the Move
Migrating to frictionless allows companies to get out of their customers’ way and enables complete autonomy. To do that, customers have to be able to be successful with a product on their own in a relatively short time period. It’s possible to cover up some product user experience challenges with a traditional sales, demo and heavy-handed onboarding process, but there’s no way around that with a frictionless model. Until companies have a great UX, frictionless won’t work.
One example is ezCater, a nationwide marketplace for business catering that generates a lot of data from more than a dozen applications and needed to replicate it all into its data warehouse. Using a frictionless model, ezCater was able to get started with its data tool in minutes and replicate data into its Amazon Redshift data warehouse. Once the company was successful with its first data sources, it went deeper and got involved in the Singer open source project, building its own integrations to run on Stitch as well.
Frictionless isn’t right for every situation, and a multi-product company may benefit from only adopting it with certain products. When evaluating the frictionless model, companies should prioritize their product where a fast time to value without help is most realistic and focus on making that product successful with a frictionless model. It is not beneficial to spread these efforts across the entire portfolio. Ideally, a small team can focus on this one product autonomously and to iterate quickly without being constrained by the rest of the organization.
Friction Points of Frictionless
Enterprise companies may be hesitant to implement a frictionless model because their products are generally more complex and costly. While there is high risk, there is also the potential for high reward. Making the shift to a frictionless model enables a faster time to value, better customer experience and increased efficiency.
While this is appealing, there are some product categories where frictionless isn’t an option. For example, a large public company isn’t going to sign up for a free 14-day trial of a new accounting system and swipe a credit card at the end if it goes well.
Committing to Success in Frictionless B2B
Transitioning to frictionless involves giving up control and venturing into uncharted territory, so it’s natural to be cautious about taking the plunge. Frictionless requires different skill sets from the traditional sales model, and success requires employees to learn new things. While some initially may not be sure where they fit in, a larger number of happy customers typically makes everyone at the company more effective at their jobs. Instant gratification is extremely valuable, and it allows customers the flexibility to operate on their own schedule.
The frictionless model allows a more accurate evaluation of product capabilities and experience. It creates a higher velocity of customer acquisition, better customer experience, faster sales cycles and a more productive sales team. To take advantage of these benefits, it’s critical to ensure that the move to frictionless will be an intentional and committed one. If companies can devote themselves to frictionless, both the company and their customers will cash out on the transition—just like PayPal and Venmo.
When a developer pushes code to GitLab, Jenkins will trigger a predefined job using webhooks.
The Jenkins job will pull the code from version control using Git; it builds the code and makes the package as .jar file using the build tool SBT. This .jar file can be deployed into a Hadoop cluster with the help of a Spark command.
Once the deployment is completed in the Hadoop cluster, the application will start running in the background.
Initially, we can see the current running application in Hadoop (see Figure 1). It has an application ID, which is in a running state.
Figure 1
If we click the tracking UI, which is Application Master, it will navigate into the Spark streaming page.
Figure 2
In Figure 2, we can see batches are running in 40 seconds. For this scenario, we are changing from 40 seconds in the code.
When a developer makes changes to the code, he will commit in his local machine and test his code, then push to remote repository. I have updated steaming time from 40 to 50 seconds and committed.
If we can specify the Jira task number in the commit message, the same comment will be updated in the Jira task as below.
Figure 3
In the Jira application, we can see our commit message as comments.
Figure 4
GitLab and Jira integration process:
Install Git plugin to pull code from GitHub repository and SBT plugin to build and make a package as a .jar file in Jenkins.
Configure the Jenkins job under source code management and provide the Repository URL along with credentials and branch details.
Figure 5
Optional: Set webhooks to automatically trigger the Jenkins job when the push happens in GitLab.
Figure 6
In the “build” section, add the parameters clean compile package in the Actions field, which will build the code and create a .jar file.
Figure 7
Once the job has been triggered in Jenkins, monitor the Jenkins console for the next step and errors, if any.
Figure 8
Optional: If we have configured SonarQube, it will analyze the code files and provide the result in the SonarQube dashboard. This allows us to know the code quality, code coverage vulnerabilities and bugs to improve efficiency of code.
Optional: To maintain the versioning, we can upload our *.jar into Nexus/Artifactory.
Once .jar has been created, we can keep it in a specific folder and trigger a Spark job. This can be performed by triggering a Spark command from Jenkins. Execute the below command to submit spark job:
As many industries are going through a wave of digital transformation, a number of key technologies and principles are being deployed to business advantage. One such principle is DevOps.
This collaborative principle is proving to be extremely helpful for businesses in their pursuit of customer satisfaction and beating their competition.
The DevOps trend is growing, as cloud providers including AWS, Azure and Google Cloud are moving faster in upgrading their DevOps services and tools to address business needs.
According to a Google Cloud and Harvard Business Review Analytic Services report, “two-third of companies that use DevOps have seen benefits impacting their bottom line, including productivity (67 percent), increased speed to market (70 percent), innovation (66 percent), customer relevance (67 percent) and product/service quality (64 percent).”
While most companies are already reaping the benefits of DevOps practices, some organizations are still doing their homework. Here are seven tips to help you understand how your organization can use DevOps to its advantage:
Begin with a Small Project
It’s always best to start with a small project before you start engaging DevOps practices on a large scale. A pilot project will enable you to understand the core capabilities of the DevOps process and how you can map them to your business objectives.
Utilizing Open Source Tools
Using open source tools will keep you in touch with current trends and practices. Open source tools are easily available and easy to integrate. You can use these to enhance your DevOps experimentation.
Introducing Security
The DevOps process faces a threat in terms of security, which can be disruptive to an organization’s reputation. Hence, it is advisable for organizations to introduce security at the early stages of the DevOps process. Additionally, it saves a lot of time and resources, which are very crucial aspects of the DevOps process. The concept of DevSecOps is a wiser approach as it includes security all through the software development lifecycle (SDLC) process.
Make the Most of DevOps Best Practices
Looking for a process that drastically improves productivity and reduces time to market? DevOps best practices are designed to increase the pace of software development. With practices spanning site reliability engineering (SRE), end-to-end automation, continuous integration, testing and delivery, proactive monitoring and more, your team will be able to utilize their time effectively and devote their attention to other important business-driving processes.
Enhance Team Skills
The key to bringing out effective production results is having a skilled team that is equipped with the necessary training. Therefore, it is essential for organizations to provide their employees with a proper understanding of the organization goals in general and the processes employees are part of. According to the report, three-quarters of the best DevOps teams said they provide hands-on learning experiences with code labs and projects exercises.
Avoid the Blame Game
DevOps aims to bring about an increased pace of operations and fast learning, among employees. But most of the time for any new process to fall in place, individuals involved have to experience failure. And with the failure of the first project often comes the blame game. However, organizations need to understand that failure is the initial step to achieving future success. Moreover, firms should adopt the policy of “fail and adjust sooner.” The experience of learning from mistakes will take you farther along in your DevOps journey.
A DevOps-Friendly Environment
A DevOps-supportive culture is incomplete without the above exercises. Hence, it is essential that organizations bring about an environment that provides room for shared goals, improved transparency and making growth-driven decisions.
So, industry change-makers: Are you ready for your DevOps experience?
