by admin | Aug 10, 2022 | DevOps Summit 2022, Whitepapers |
Author
Raminder Rathore : Chapter Lead, Canada DevOps Community of Practice (Toronto) & Global Head – DevOps Practice HCL Canada Inc.
Recap
In our last blog – Reshaping IT Services in DevOps World , we looked at how IT services are evolving to adapt “DevOps as a Service”. Different organizations are redefining their ways of working and are investing time and money for upskilling their people, adopting new tools, creating new cost models and propositions. They all understand that this shift is necessary to mobilize talent. New team structures are formed in the ecosystem that is supported by shared services groups – some call them COEs – Center of Excellence; while others call them COPs – the Center of Practices. This service group continuously measures and tracks DevOps maturity across all the teams and they are in charge to guide them towards success. This shift is a journey that needs proper planning and execution and cannot be done overnight. The senior leadership organizes and plans for rolling out the new model. They identify ambassadors across the business/technology units who act as the first citizens to understand the change and broadcast the information to their teams. But, is there a standard to be followed for rolling out the new structure?? The answer is “YES”, there are multiple models available to refer to and adopt, BUT as the saying goes – “one size does not fit all”. Hence, organizations can refer to standard models but they should tweak the recommended structure that fits in their ecosystem and is well accepted by their teams. Well, the initial steps towards this change will have speed breakers. The leadership needs to stay focused and work with the teams to facilitate cross-skilling and support the inception of new roles and responsibilities.
A reference model for “DevOps as a Service”
As organizations commit toward a new change in their ways of working, it does include-
- broadcasting the purpose,
- revisiting and upskilling teams,
- changes to their team structure,
- investments in new tools, and
- continuously monitoring the journey towards the change.
The new teams are renamed as “pods” / “squads” or simply as “product teams” (there may be more). These teams are self-organized and they collaborate with other teams to roll out products/services. These structures as vertical groups that are supported by horizontal services that include COPs/COEs, PMO, Finance, Cybersecurity, Platform, and Operations teams. Again, the verticals and the horizontals can have different names but they all need to stay focused on the organization’s goal – which is to drive agility and DevOps practices. Introducing new roles ignites this transformation and is very helpful. Take a look at a sample model below-
Every product or service may have one or more pods or say, squads. Each squad is a self-organized team they go by the principle of “we build it, we run it”. Each pod follows the waterfall or agile pattern depending upon the nature of the product/services. The idea is to have small teams that can run independently to develop, test and deploy applications/services. These products/services need supplements, they need expertise from other areas like security, automation, operations, etc. These horizontals existed before too, but in the structure, these teams are rebuilt to work in a collaborative fashion with limited hand-offs and proactive participation. The PMO horizontal works closely with COP to broadcast the new changes, define the purpose for the new change, and ensure the new pods/squads understand and practice DevOps. There are organizations that have a horizontal that offers DevOps services to the verticals. This could be a function of the COP or an automation team that gets refreshed as a team that offers DevOps tools as a service. They are in charge of the DevOps tools and ensure that these are in a working state for the product teams to consume. Such COPs also track product teams’ performance by deriving project and program level metrics that serve as a scale for measurement. They also build standard pipelines that are leveraged by the product teams who now do not waste time installing DevOps tools and building pipelines from scratch.
Thus, each horizontal is committed to building a quality product along with the product teams. So, before such new structures are created, everyone in the organization should be enabled with the purpose of the new structure, trained on new technologies, and agree to work together as a team. The above snapshot is just a sample model, this can further be refreshed based on the organization’s needs. The core idea is simple – develop modular teams that work as one team thereby reducing risk and increasing productivity.
Conclusion
The term “DevOps” has evolved over the past decade and has taken various forms. Organizations need to understand and interpret “DevOps” for their teams. They need to be sure that this concept brings in trust and transparency to their teams. And this is made possible by upgrading or changing their IT operating model. Developers should not be held responsible for DevOps tooling, they should concentrate on building quality products. Horizontal services in the organization need to take responsibility to complement the product teams. The movement towards a DevOps organization is a journey that evolves with learnings and experiences. Proper coaching and leadership support enable organizations towards a successful path.
Looking for some more references with examples? Check out the “Hands-On guide to Agile Operations” a guide to implementing Agile, DevOps, and SRE for Cloud Operations.
Want to be part of the Canada DevOps Community of Practice to contribute? Get in touch with our team or connect with Chapter lead in your specific location.
by admin | May 27, 2022 | DevOps Summit 2022 |
In many industry segments, carbon neutrality is becoming an important attribute for consumers wishing to choose more sustainable products and services. Have you ever thought of the explosion of ICT products, tools and services in our daily lives and how it impacts our carbon footprint? It is needless to say that the consumption of ICT services & products is continuously increasing and so is the carbon footprint of ICT. Let’s dig deeper into how the DevOps ecosystem can steer us towards not only green ICT applications but also support global mitigation efforts towards reducing negative impact.
In this blog, we will explore the DevOps ecosystem, key components for ICT services and products through which we can assess and optimize the carbon footprint and lastly how to certify green ICT services & products.
Overview
Chiara Venturini, director of the Global e-Sustainability Initiative, a Brussels-based industry association, estimated that the IT industry currently abates 1.5 times its own carbon footprint, and that could go up to almost 10 times by 2030. It reflects that we must put more focus on green ICT strategy. We do not have to reinvent the wheel, we have some research and literature on this topic. Let’s start by revisiting the 4 major pillars of green ICTs contribution (Andreopoulou, 2012)
- Energy sustainability through reduction of energy consumption/carbon footprint while production and usage of ICT leads towards a low carbon economy
- Climate change mitigation with extensive environmental monitoring, DSSs for simulating future environmental scenarios for sustainable environmental governance.
- Increase environmental awareness with information diffusion, training & environmental education
- Effective communication in environmental projects & networks
How do these major pillars connect with DevOps? Have you thought of cloud services as surplus, do you know how much carbon footprint it generates for the e-services & e-products?
DevOps can enable organizations to green ICT products and services, some of the key components would be enabling dynamic provisioning for infrastructure to take a green approach. Another way to look at it is multi-tenancy, producing software with reuse of infrastructure in mind. Optimizing data footprint can be another dimension to look at. We will explore more ideas through this blog as there might be many more possibilities. We will dig deeper into the impact, and the action we take from a DevOps perspective to move the needle in the next section.
Enabling a green ICT ecosystem through DevOps
The outlook for green ICT services is still at the inception stages, however we can highlight some of the potential areas for research and aligning actions.
1.Public vs Private Cloud footprint
The energy demands for ICT data centers, especially cloud providers are accelerating, according to many reports, some of these data centers use as much energy sufficient to light up a country. We would have to baseline these figures, let’s start with looking at CSP reports from these public cloud vendors.
- According to Microsoft’s report on the carbon benefits of cloud computing,, “Microsoft cloud is between 22 and 93% more energy efficient than traditional enterprise data centers. When taking into account our renewable energy purchases, the Microsoft cloud is between 72 and 98% more carbon-efficient.” Note: the larger the deployment, the lesser the benefit.
- AWS meanwhile advocates that “running business applications on AWS, rather than on-premises enterprise datacenters in Europe, could reduce associated energy usage by nearly 80% and carbon emissions by up to 96% for many businesses when AWS purchases 100% of its energy from renewable sources.”
- Google states that its data centers are “2x more efficient than a typical enterprise data center.”
The Carbon footprint of public vs Private Cloud, it is a difficult question at hand with limited ESG guidelines & standardized metrics to answer if your private cloud would be more green than public or vice-versa, but definitely, we can look into the possible options to optimize and align to green initiatives
So how would DevOps come to the rescue to optimize the footprint? Some idea to build upon is power saving by moving from always-on application to power off mode, saving can be up to 10%- 15%. Autoscaling is another feature that can be a possibility and prepare the applications for low and high traffic hours based on usage patterns. If your application resides on a hyper-mix of old servers/technology which is hard to auto–provision or auto-scale, try moving out and modernizing the footprint. Optimal Edge computing is another way to balance the overall consumption for bandwidth-intensive features.
Putting DataOps in perspective for green e-ecosystem
Have you ever thought of the carbon footprint while you post your vacation photos on social media? An outlook on data traffic over the internet, the growth is exponential from approximately a terabyte in1980’s to more than a zettabyte in the 2020’s. If we try to map the energy needs for the future with the data-driven explosion, we could see a correlation. Optimizing data might be the ultimate way to prevent energy use from going into hyperdrive. Efforts toward evolving DataOps practices and embedding them into your pipelines can be a useful consideration for the green digital world. Another dimension is moving data to data centers located in cooler climatic conditions if you do not have any location-sensitive information or even auto-curate the data and store it in more green locations. Let’s talk about some advanced machine learning techniques for limited data problems, including approaches for small amounts of data, this research can be useful if connected with the carbon footprint the enormous amount of data generates
Advanced DevOps features
It is needless to say that onboarding to more green DevOps features like containers, virtualization, auto-scaling & provisioning is key. Taking the dialog further making not only infrastructure green but also developers go green on coding. Examples of features like AWS CodeGuru built more insights that let us know which lines of code need the most resources — and if there is a way to optimize them.
Some other areas where we can take a deeper look is connecting architecture of application to green strategy. Moving out of monoliths, more reusable interfaces and architecture changes that reduce energy usage, fewer resources, and hence positive impact on carbon footprint.
Marketplace for carbon-neutral products and services
What if, we can create a marketplace for carbon neutral products & services where we can cascade the impact. If we would intend to do so we might have to consider future evolutionary changes and some of the next steps could be as follows
- Map out carbon footprint for products and services and identify hotspot features
- Guidelines for the financing of ICT products & services based on carbon footprint
- Certification for green ICT services & products and standardize net-zero outlook
- Decarbonization of ICT services & products through tools & processes
Our next blog will address the marketplace considerations and elaborate in detail on the action plan. Meanwhile, DevOps Summit Canada has a track on this topic. If you are interested to submit a talk now is the time. We are looking forward to hearing from you.
Sources & references –
- Green Informatics: ICT for Green and Sustainability
- The green cloud challenge
- https://www.sustainablewebmanifesto.com/
- https://www.fastcompany.com/90346595/the-internets-youtube-habit-has-the-carbon-footprint-of-a-small-city
by admin | May 24, 2022 | DevOps Summit 2022 |
Overview
Breakthroughs in technology infrastructure space through the cloud is only the starting point of a massive shift, it is needless to say there will be a wide array of services & related competencies needed to make the shift. To embrace the change and leverage technological & cultural advancement, it is important to reshape IT services for the modern ecosystem. DevOps evangelists, start-ups and communities have crafted a path, but we need to look at setting the strategic direction, planning for next-generation operating models, and setting out for a multi-dimensional transformational journey.
In this blog we would like to dig deeper into the next-generation operating models, keeping in view the talent shortage, shortening the lifespan of DevOps tools and growing demand for new competencies. While exploring the new operating models, the goal is to make it simple, yet impactful for organizations to get around, experiment and explore new possibilities and avoid the hassle of looking out for a talent pool every time there is a new capability, tool or competence needed.
Looking ahead – Adding more people, more competencies or more certifications is unlikely to solve the competence gap in an already stretched demand-supply ecosystem. With more and more companies and industry segments moving into cloud computing and modern technology areas, the crisis will be deepened. To build a sustainable operating model, we must look at new opportunities for service providers, and outsourcing companies.
Exploring a new context for IT Service providers and an exciting operating model for the organization to look at, introducing innovative ways to engage with IT service providers, in the new context. Today, DevOps as a service might be at its inception stages and it has great promise. We have a number of options based on organization preference. Instead of using a service offering for one big transformation, or onboarding once in a year or once in a multi-year, why not have it as an option for a month or even a day? Let’s explore this further.
What is fueling the interest in DevOps as a Service
Many companies have embarked on the journey of next-generation IT services, and while we witness some commonalities in their journey and challenges which are fueling the need for DevOps as a Service model, especially
- Cost structure and the existing economics, we can’t keep adding up the fixed cost to products so the notion of having the right-sized team inhouse for building DevOps capability to support everything we do is highly unlikely to be achieved
- An array of competence and skill set are needed and the ever-increasing lead-time to onboard the required talent under one roof.
- It’s no longer about a non-Core function which was IT services, baked at the side with a bunch of in-house resources or outsourced for cost efficiency purposes. DevOps is needed and if not done right will impact revenue.
- Multiple independent and siloed initiatives inhouse, provides speed and focus to improve the existing setup but fails to organize themselves effectively for long-term sustainable impact
- Risk, the marketplace for DevOps tools is an attractive proposition but it brings challenges. Without focused control measurement, it is highly likely we would either create reliability issues or burnout /overhead within SRE & DevOps teams
Changing context, new opportunity for IT service providers
Traditionally the IT service providers have operated with M-Models and U-Models, it’s time for them to rethink that approach, long-term outsourcing contracts are less likely to happen. How do we onboard to a DevOps as a Service model then? What value creation is expected?
- Infinite bandwidth and Zero-latency – When we connect the demand and supply value chain in a T-Model approach like Uber, we create possibilities of the abundance of talent through optimal use. DevOps Engineers and SREs interact with potential clients through a digital platform.
- General Purpose Pipelines & Services – Some of the needs are fundamental, general-purpose, and reusable. These services provide horizontal support. Not every company should struggle to hire talent, there must be a better way to get this.
- Small and Medium Business Services – “Think small first” approach to technology onboarding and related services. The big companies have an unfair advantage and access to the talent pool, unfortunately, this poses a challenge to the survival of small/medium businesses
- High-performance Community collaboration hubs – Most will need a pulsating environment by, with, and for entrepreneurs. DevOps as a service with a community around it creates a possible futuristic approach.
Reshaping our operating Model to embrace DevOps as a Service
To ensure we move the needle in the right direction and shape up the operating model to embrace DevOps as a service, we need to be prepared to address some of the associated challenges, primarily cost structure & portfolio streamlining for such a service. Existing IT services companies could correlate the portfolios with the business need of different segments, some ideas to build upon this perspective are as follows
- DevOps as a service portfolio for small & medium enterprises may consist of special purpose DevOps services, express services, and expansion/modernization services. The monetization of such services should be proportionated to the number of users typically not hurting the margins for small businesses, a licensing model for such services could be experimented with based on several consumers rather than complex service contracts.
- DevOps as a service portfolio for mature enterprises may consist of an ‘innovator’, a ‘Centre of expertise’, and an ‘engine for change’. An outcome-based pricing model for such services based on “Enterprise Zones” or “Business Unit Zone”, from first generation to next generation and mapping the optimized outcome of each of the zones tangibly to cut the ‘long tail’ of under-performing business zones
- DevOps as a service portfolio for reliability & security may consist of a distinct emphasis on critical infrastructure for the regulated segment. Risk and reward sharing model. Strict SLAs and high focus on predicting, detecting and recovering.
- DevOps as a service portfolio for the Community may consist of free or subsidized offerings for community ventures. To broaden the services for the greater good.
Metrics & Service Levels for transforming IT service models
The choices of DevOps as a service portfolio are wide and at inception stages. Imagining the future of such service would mean we keep ourselves accountable to the business objective in the long term. Organizations will need to adapt to the changing demands, aspirations, and expectations of end users & our customers, with some key service level indicators in mind, outlined as follows
- Modularity, sharing, and reuse
- Responding in real-time to user demand
- Next–Generation Experience
- Reduced Risk
Conclusion
Shift towards a large proportion of DevOps as Service contracts to enhance the mobility of talent and make it accessible to all, might be the greater good in making. Radically dismantle the 9 to 5 model and create an ecosystem of user & customer-based services. We will explore more dimensions of DevOps as a Service in our next blog and stay tuned for an update from us, we always look for feedback – complete the survey and win to collaborate with our leadership team on the next blog
