— ROELBOB
Category: Blogs
-
Gartner Evaluates APM Tools for DevOps
In 2009, Gartner analyst Mark Nicolett created the Critical Capabilities report. Over time, this document became paired to individual Magic Quadrant reports, and in 2014, Gartner mandated that Critical Capabilities be paired with each Magic Quadrant. Instead of graphically plotting vendors on a x- and y-axis, this research takes a deeper look at a product and its fit for specific use cases.
So how does this pertain to DevOps?
In its latest “Critical Capabilities of Application Performance Monitoring” research, Gartner notes, “Because of its wide lifecycle purview, the DevOps release team often leverages many of the capabilities found in APM suites.” Since the foundation of DevOps is to foster collaboration among the two, typically disparate teams, modern application performance monitoring (APM) solutions are geared perfectly to help encourage this feedback loop. “When examining the capabilities valued by this buyer, APM tooling is critical when attempting to quickly assess the quality (and effectiveness) of a recent release. Detecting and diagnosing issues must be done quickly, which often requires in-depth data sourced from multiple, integrated tools,” according to Gartner.
“Much of the activity of APM technology is focused on detecting and providing insight into root causes. Identification of the impact on system and application resources is based on existing (or proposed) transaction-level trends,” the report continues. “This capability provides IT operations and DevOps release teams with the ability to tell the (line of business) and application owners the potential impact for any planned changes or continuation of resource consumption trends. Although capacity-planning tools have often filled this role, APM suites increasingly offer predictive analytics capabilities for shorter-term horizons”
Of course, we can’t ignore the key to DevOps success: culture. However, no tool—no matter how good—can foster the right type of culture. John Rakowski, my current colleague and ex-Forrester analyst, wrote a compelling ebook on the intangibles that successful DevOps teams need.
The Critical Capabilities research report provides a comprehensive and technical product analysis ranking APM suites from 15 vendors on critical APM capabilities across five different usage scenarios, including DevOps. The capabilities assessed for each use case included business analysis, service monitoring, anomaly detection, distributed profiling, application debugging and workload planning.
The vendors evaluated were AppDynamics, AppNeta, BMC Software, CA Technologies, Dell, Dynatrace, Hewlett Packard Enterprise, IBM, JenniferSoft, ManageEngine, Microsoft, Nastel Technologies, New Relic, Riverbed Technology and Tinygun.
The report is free of charge and can be downloaded here.
-
Case Study: Sauce Labs Covers Animoto’s Testing Needs
Animoto’s web and mobile platforms enable businesses and consumers to drag and drop stock and user-defined visual and audio elements to create videos via a tiered monthly subscription service. Animoto updates service features with increasing frequency—some of them several times a day.
“We have a broad range of applications and features including an online video maker application, where we enable users to import videos and video elements from all the known, established sources such as Facebook and through Dropbox,” says Siddharth (“Sid”) Jain, VP of Engineering at Animoto. “They can then export videos out to a variety of venues such as YouTube.”
Animoto must iterate new innovations continuously into its application/platform for high-quality yet simple video creation to compete with similar solutions in the marketplace such as WeVideo and Stupeflix. This fast-paced development process is challenging, since Animoto must update separate versions of its software for the web, Android OS and Apple iOS (both iPhone and iPad). “The mobile apps are largely consumer-focused for very easy, on-the-go, frictionless video creation and sharing, while our web apps feature server audiences of professional photographers, educators and small businesses,” says Jain.
In addition to testing service capabilities of different versions of the video maker application, Animoto must test the on-boarding/registration flow and the free product experience, where users get their first taste of Animoto. “We do lots of interesting things such as testing support for multiple currencies around the globe and running continuous multiple AB tests to ensure that the free product experience is working,” Jain notes.
Notable Animoto testing includes user funnel testing in a simulated user flow environment starting at sign-up and continuing through video creation, feature exploration and the upgrade experience. “We test this several times a day on the different platforms,” Jain says, noting Animoto tests for the seamless success of import and export of videos and video elements to and from Facebook, Dropbox and YouTube. “The emphasis is on ensuring the quality and consistency of the user experience, i.e., making sure that nothing goes out that breaks revenue in terms of service.”
Porting to Sauce Labs Promotes Progress
Sauce Labs‘ cloud service helps Animoto scale up and out instantly to test Apple/iOS versions of its application so it can meet the high standards set by Apple and ensure fast inclusion of new app versions in the Apple App Store. This helps Animoto to compete by getting new innovations and features to market more quickly. “The biggest advantage to using Sauce Labs is that we don’t have to create or maintain a test lab internally,” says Jain.
This accelerated testing speed is especially important since the app must adapt to every new iOS version while maintaining backward compatibility. “It would be a very nightmarish thing to do this all manually,” he says.
In addition to faster testing, Sauce Labs is helping Animoto ensure that testing was delivering on its promises of software improvement through accurate feedback. “We used to be religious about doing extensive unit tests. Now we emphasize integration tests over unit tests because we got bit by unit tests that were all green even though the software functionality was broken,” says Jain. “Now we have a balance between unit and integration tests while frontloading the latter with tests of customer-facing functionality and collecting fine-grain feature use data.”
The comprehensive testing helps to ensure that users aren’t shying away from certain features and that features are not broken. Frontloading uncovers regressions very early so the Animoto developers dedicated to fixing them can catch them before they lead to breakage.
Sauce Labs helps Animoto shrink technical debt. “Debt rears its head in awkward ways. We do get surprised, but having good test coverage allows us to know where the app hot spots are and to have feedback to fix these and verify changes swiftly,” says Jain.
Results: More Stability, More Capacity
“We have been able to reduce testing time from three hours to under 30 minutes for some tests,” says Jain. “Thanks to Sauce Labs’ cloud, we added VM capacity, moving from 20 VMs to 45 VMs for the testing environment.”
-
Top 5 Reasons to Back Up Your OpenStack Environment
I am a big fan of lists. If you recall the movie “High Fidelity,” John Cusack’s character Rob and his co-workers—armed with an encyclopedic knowledge of all things musical—compile “top five” lists for every conceivable occasion, openly mock the tastes of people, and, every so often, sell a few records. In the spirit of a lists, here are the top five reasons to back up your OpenStack environment. We thought that it would be helpful to many.
If you’re currently working with OpenStack clouds, or are in the process of embracing it, you need to include backup and recovery for OpenStack on your list of to-dos from the start. You may ask, “Why? I have orchestrated/automated everything, I just need to spin resources up and down.” Cloud environments are fundamentally different from the virtualization we have become used to. Virtualization relies on infrastructure for resiliency. In the cloud, distributed applications are responsible for their own resiliency, and are independent of the underlying infrastructure. Therefore, cloud apps need backup and recovery options, lest you face a complete machine, data or file meltdown.
We’ve compiled the top five reasons to backup your OpenStack environment. Take a read and it will become clear why you must include backup in your OpenStack plans.
- Compliance — Compliance may seem like an issue for only certain industries—finance and health care come to mind—but nearly every organization has to deal with compliance issues. For some, it’s compliance to external regulations, while for others it’s simply complying with internal policies and best practices. Backup for OpenStack is an essential component for compliance; it ensures the availability of the data at a specific point in time within your OpenStack applications. I was recently involved in a dialogue/string on LinkedIn watching experienced OpenStackers go back and forth debating “pet vs. cattle.” “I am getting tired of it,” one person said. “This is cloud. It’s about scaling up and out … With automation and orchestration there is no need for cattle.” This conversation went on for days. Theory is great. Practice is reality. What people failed to discuss is that compliance or the business units will drive many requirements (such as backup) either today or tomorrow. End of story.
- DevOps — Backup is often the forgotten tool for DevOps. Containers are great to use, but the ability to test with real data is an issue. The reason to use backup is quite simple: test and development. With a copy of a production environment, you now can test upgrades and new features in your agile development process. Furthermore, if you lose a machine or your data, or you end up with corrupted files while in the middle of testing or development, your life will be much easier if you have an appropriate backup solution in place. Restoring machines, data and files is a better option than re-creating them entirely. Cookbooks and recipes are great as well, but you still need to couple it with the appropriate “ingredients.” It is like playing with a fake kitchen as a child … do you want to make breakfast with plastic pancakes and toast? Nothing beats the real thing. Yes, more resources are required for one over the other, but when something goes wrong—it is unfortunate—people point fingers.
- Disaster recovery plans — While the terms “backup” and “disaster recovery” often are used interchangeably, they are actually not the same thing. You might have what appears to be a great recovery environment (ideally one that mirrors your production environment for high availability), but without a comprehensive backup solution, your recovery might not be the painless experience you expect it to be. Perhaps the solution for intelligent disaster recovery is to marry backup with a Swift environment so you can recover from any point in time, anywhere in your organization.
- Save time — Often recovery can be a frantic process, driven by a business need to have the machine, data or files recovered as soon as possible. Or, more likely, sooner than possible. If you are trying to re-create something under that type of environment, there’s a likelihood that mistakes could be made. This becomes increasingly true the more complex and mature your cloud becomes (think about the growing number of workloads and applications). A much easier approach—one that provides you with peace of mind—is to have a comprehensive backup solution ready and available for when you need it. There’s also another reason backup can save you time: When you have to re-create the lost information, you are taking your time away from something else—and that means you are taking a big hit to your productivity. Save yourself and your organization a big headache with backup.
- Security and forensics — You never know when you are going to be asked to provide data or files related to a security issue or a forensics investigation. The right backup solution not only makes it easier to assist with the activity, but think how good you’ll look by being able to deliver the information the forensics team needs quickly.
Are you currently looking into backup solutions for OpenStack? Now that you know why you need backup for OpenStack, learn more about how to backup OpenStack.
-
Embracing DevOps in the IoT Era
To those of us struggling to cope with the challenges of delivering software over the Internet of Things (IoT), DevOps can be the savior.
Delivering software over the Internet is no easy task, and delivering it over the Internet of Things is even more formidable. How do you deliver software to so many “things,” many of which are “loners” unconnected to the rest of the world?
What’s encouraging is that the software management processes and tools that we know and have learned to love still work in the IoT era. In fact, not only do they work, they are essential.
We need teams to work together more smoothly and communicate more quickly to mitigate the higher technological risks. DevOps processes and tools, therefore, are critical in the IoT era because they facilitate smooth, well-oiled collaboration between teams.
A Typical IoT Scenario
Consider a scenario in which you need to develop a “smart” parking system for a “smart” city. The system will involve multiple sensors in the parking lots, a display device in each parking area along with communication equipment, a central server for control and analysis and a smart device in each car.
Drivers can check how many slots are available in nearby parking lots on their automobile devices and navigate to the appropriate parking lot. They also can book slots in advance and start paying from the time they book the slot. When they leave a slot, the parking slot sensor automatically detects that the slot is free and updates a central server. The central server transmits slot availability to the car-based devices, where they become visible to drivers. The central server also generates various kinds of reports and performs various kinds of high-end analysis.
As with any conventional Internet system, there are multiple software components. All of them have their respective delivery (development, testing and deployment) streams. These streams need to work interdependently and collaboratively, and they need centralized configuration management and dashboards.
The Scale and Diversity of IoT
The differences and challenge, however, lie in the sheer scale of deployment, the diversity of deployment environments and the multiple deployment channels. As you can imagine, any large city will have millions of cars, thousands of parking lots and, hence, hundreds of thousands of individual slots. The number of deployment devices easily can run into the millions.
In the interest of preventing monopolies, not all the parking sensors will be from one manufacturer. The same holds for the car-based devices. While certain standards can be enforced, not all manufacturers will adhere to one universal protocol. It will be necessary to allow multiple communication and security protocols on these devices. This multiplicity of protocols can complicate software deployment on the devices.
Other Considerations
What makes the entire deployment process even more complex is the fact that most of the deployment will be done over the air (OTA). Given that OTA deployment is susceptible to radio-frequency interference and other transmission issues, the deployment process must allow for more robustness than conventional wired deployments.
There are even more factors to consider: A city-based system can be extremely dynamic. New cars get registered every day, adding to the traffic. New parking lots may be built every now and then and get integrated into the smart city system. New kinds of chips from new sensor manufacturers could be added, as mentioned earlier, to increase competition. New, more sophisticated car-based devices coming into the market might offer to host the smart parking software. Of course, as in conventional systems, new functionality and patch fixes would be released frequently. Finally, as the system becomes part of city life, its utility as an analytical tool could increase beyond analyzing parking trends to other spheres of activity.
These business and technological factors can exert tremendous evolutionary pressures on the system. A smart system in a smart evolving city must evolve, too. Yet, no change anywhere in the system must be allowed to break the system anywhere else. The chances of this happening are higher in an IoT system because interconnection protocols have not matured enough to become universal and because physical device conditions can never be predicted perfectly. For instance, a single extra field required by the central big data server could place an unsustainable additional burden on the fragile radio-frequency system in the parking lot and bring down the entire data transmission.
How DevOps Can Help
To offset the increase in technological and business risk in the IoT, we need robust processes and tools that mitigate the additional risk by improving communication and collaboration between teams. Tools that have the following features become indispensable:
- A centralized dashboard providing a cross-stream view of the software development;
- The ability to trace linkages between all related software artifacts across streams and lifecycle stages, given the stressful nature of interdependencies between streams; and
- A tool that can detect broken linkages.
The tools also need a well-oiled DevOps management culture that encourages close collaboration and rapid communication between development and operations.
IoT heightens the need for close collaboration between multiple software streams and within streams between development and operations. Adopting a DevOps culture and DevOps enabling tools is the way to offset the risks of software delivery in the Internet of Things.
About the Author / Vidhya V. Kumar
Vidhya is an advisory software engineer at IBM. An evangelist and practitioner of agile methodologies, continuous delivery and documentation, she has about 10 years of experience in the IT industry. She is a subject matter expert in DevOps, application lifecycle management and search methodologies.
-
3 Skills Developers Should Master in 2016
The era of mobile and web is upon us, which has caused nearly every business decision-maker to ask the question, Is now the time to hire a developer to build our app or website? In 2016, businesses are going to be looking for the best developers to join their team and help scale their business. We’ve already started to see this trend, as a recent Harvey Nash Technology Survey 2016 found that developers are the most sought-after of all technology personnel.
To stand out from the pack, developers must master the critical skills businesses are looking for. The most valuable developers will be those who can adapt to the changing technology landscape and further hone their craft to help companies scale and solve specific business challenges.
To stay competitive in today’s market, developers need to invest in these three skills to be relevant in 2016 and beyond.
Master the Skills to Scale a Product or Service
Startups increasingly are evolving from early stage concepts to building a growth model to take their business to the next level. To be an asset today, developers need to master and specialize in scaling technologies that are key for businesses looking to expand their customer base and focus on technological innovation.
There is a demand for developers that have not only a breadth of experience in bringing an organization up to scale but also depth in their technical skill set. Having the ability to work on major systems, support large amounts of traffic and customers and maintain the system for several years are critical competencies that companies will be looking for.
Also, having a data model or database experience is very important—NoSQL solutions such as Cassandra, CouchDB or Riak, as well as traditional data sources such as MySQL, are in high demand. Middleware languages such as Java and Golang also are an important part of a developer skill set when building services and APIs.
Understand the Customer Perspective
When building a technology solution, an engineer must be able to look at the product from a customer’s perspective to understand what problem the product is fixing. While technical skills in developing a product and user experience (UX) are very important, the ability for a developer to understand and create a product that solves a customer challenge far outweighs the focus on building the most elegant software.
Engineers who are able to demonstrate project management skills and have experience around scaling infrastructure and ensuring the platform is robust will be in high demand. Businesses increasingly are seeing a need to support growing customer bases and traffic with utmost end-user reliability.
Become a Subject Matter Expert
There is a gradual shift in the developer community, in which engineers are focusing on specializations and becoming subject matter experts. There is an opportunity for developers to create career highlights by merging their talent and passion with opportunities.
Developers are encouraged to identify an area they are passionate about and focus on refining those skills. By being able to find these opportunities that build on their passion, these developers can demonstrate they are able to solve a challenging problem for a large number of users—a competitive skill in high demand across the industry.
The overarching strategy of a successful developer career is to invest in learning how to scale a product or service, understanding the customer perspective and becoming a subject matter expert. Investing in your skills as a developer in 2016 can lead to a longer, more fulfilling career.
About the Author/Sha Ma
Sha Ma is the senior director, Software Engineering at SendGrid. She led development teams at both startups and Fortune 500 companies prior to joining SendGrid. In her current role, she drives strategic planning, development and management of large scale projects. Ma is a graduate of MIT where she earned both her bachelor’s and master’s degrees. -
Taking Stock of DevOps: Where to from Here?
Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.
First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.
Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.
So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:
… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.
That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.
DevOps Works Because It’s Good for Business
Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.
That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.
An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.
Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.
DevOps Shouldn’t Start and End in IT
The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.
This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.
Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.
From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.
-
Measuring the Cost of Service Creation & Adoption
Adopting and implementing DevOps isn’t an overnight project. It takes time and effort to determine how it best fits into your organization—and what benefits your organization will realize as a result.
Creating an enterprise-class DevOps service is typically done in one of three ways, depending on the organization, its leadership and its employees. Each has its pros and cons, and each has a number of factors to consider.
A Fully Centralized Model
In this model, tooling decisions are done in a central service provider group for the entire organization. Tools are managed centrally and standards are created centrally. DevOps automation creation (at least the templates or frameworks) is done centrally. This model is highly advantageous for organizations with a wide variety of technology platforms (think large population of legacy apps) and use many technology components for their apps, such as multiple types of databases, middleware and operating platforms, for example.
Not many large organizations are ready to scrap what they have in the application portfolio and start over using the cloud and containers and develop in a singular methodology. Using a centralized model, companies can continue to improve upon their years of investment in legacy applications and adopt a DevOps continuum without starting over from scratch.
This also is the lowest-cost model, as tooling is standardized and administered from a central point and licensing can be negotiated to maximum effect. In addition, labor (generally the highest ongoing cost of any service creation and implementation) is minimized by centralizing it. Training costs also can be minimized by establishing a centralized training program for all impacted audiences. Companies can change their incentive programs to achieve hiring objectives and business results as priorities change—something that isn’t practical in a decentralized or federated model.
A Fully Decentralized Model
In a fully decentralized model, tooling decisions are determined and managed by each development team. This has the advantage for shops with small numbers of applications or singular methods of development—fewer applications are better candidates for starting over with cloud or container integrations and can take advantage of the newest technologies from the starting point, if needed.
Shops such as Etsy or Facebook seem massive, but from a user point of view, they really only present a single application that needs to be maintained and improved over time. Instances like this may favor a decentralized model because the actual number of application candidates may be highly limited—sometimes only one.
This model typically represents the highest costs, as repeatability and standardization can only be measured at the development team level. As such, this is practical for a very limited number of applications, or technologies; if those numbers grow, the strategy quickly becomes untenable. In addition, this strategy has an uncanny history of pulling development resources to do the DevOps automation engineering that needs to be created and maintained. Typically, the highest skilled developers are assigned these types of duties, and thinking in terms of templates and frameworks is rarely their first approach. Developers tend to be expedient, and believe they will always be there to make sure it works. This also can reduce the potential for repeatability and predictability (raising costs).
A Federated Model
In a federated model, tooling decisions and standards are done centrally, but management and operations of the tools are performed by a limited number of subservient organizations (often by line of business). Centralized templates may or may not be viable depending on the variability of the business units they serve. The chief advantage of this approach is the segregation of tooling and reporting by business unit (typically) without having to build that kind of segregation in to tools that were not designed that capability in mind.
This model also has the advantage of increasing the speed of adoption, as several parallel efforts can take place at the same time and spreading engineer resource demand across multiple organizations. It typically makes the most sense in larger organizations with multiple business units whose application portfolios that would benefit from an onboarding to DevOps.
What’s more, a federated model may be the most cost-efficient. Labor costs will be inherently higher as functions are replicated from business unit to business unit; however, that replication will result in increased adoption rates and project completions (you get what you pay for). If business units are able to leverage centralized templates for each technology type, adoption rates become an order of magnitude faster (or have that potential). Tooling costs still can be negotiated centrally, even though management will occur in the business units. Again, there is hardware replication from business unit to business unit, but the ability to segregate users, permissions and operations down to the business-unit level can save tremendous labor costs if development was the only other option to create that capability in tools not designed for it.
Adoption Costs
Measuring the cost of adoption requires focus, no matter which method you employ to create the DevOps service. Applications moving to DevOps are said to be onboarded (where the original build, deploy, test and release automation is created). To successfully onboard an application requires education of the sponsoring executives, training of the impacted developers and testers, and coordination with the change and release managers.
Collection of meta data about the behavior of application components is no small task, requiring frequent follow-ups and action items to reach completion. The effort to onboard applications to DevOps becomes the first cost for estimation and tracking as the application portfolio is attacked.
Even after onboarding of a given application is complete, costs continue. The terms “continuous delivery” and “continuous integration” should also infer that application development methods “continuously” evolve and may adopt new technology components. Significant changes may occur that require revisiting the DevOps automation to adapt to these ongoing revisions and updates.
While this work is rarely as extensive as the initial onboarding, it is measurable. Work of this nature is usually referred to as BAU (business as usual) and represents the second significant cost of DevOps services that must be measured and tracked. If no thought is given to this work effort, inevitably the team assigned to do onboarding will be distracted by the BAU requirements until they reach the point where no new applications can be completed.
Staffing cost estimations can be presented at the component level for both onboarding and BAU efforts. For example, if one DevOps engineer can onboard 20 components per week (assuming familiar technologies within a given portfolio), and if the general ratio of components per application is 4:1, then a given DevOps engineer can successfully onboard five applications per week. If the engineer is never distracted with BAU, this can continue until the entire portfolio is onboarded. However, my experience has shown that for every 20 applications completed with onboarding, the BAU work effort can absorb nearly a full DevOps engineer. So if you start with a team of 10 people, you will onboard only 200 applications total before the entire team is required to focus on BAU work effort and has no more bandwidth to continue onboarding new apps. Understanding this demand, and learning how efficient your particular engineering team is, will be key to managing costs while completing the onboarding efforts of large application portfolios.
