devopsy.kinsta.cloud

Category: Enterprise DevOps

Shifting to Product-Centric Work in Utilities
Large organizations across the services spectrum are transforming from project-centric operations to product-centric way of working. Customer centricity is driving this transformation, as product-centric organizations put customers at the center of everything they do. Such a transition is largely dependent on how information technology solutions are deployed in the said organization.

This article looks at the importance of a product-centric way of working for utilities organizations, particularly the power sector, which is looking to transform customer interactions by revolutionary use of new digital technologies and solutions such as smart metering and smart homes.

At the onset, power utility organizations should focus on shifting to a product-centric way of working in areas that show promise to deliver innovation and digital enterprise such as customer analytics.

Fig. 1: Current State of Play in Most Power Utilities

Fig. 1 outlines the current state of play at most power utility companies, where organizational silos and application silos lead to customer challenges in understanding the products and services offered, as well as productivity losses and an increase in reaction times to changes demanded by business and regulation.

In most power utilities, silos exist in business units which are reflected in how the applications supporting those business units are organized and managed. This leads to duplication of effort, work and applications, as well as a waste of time and resources. Customers are often confused about multitudes of service offerings and various channels. There is also an inherent delay in responding to challenges thrown by changes to regulation and/or business environment.

This is changing, though, and one can look at the “meter to cash” processes for a reflection of market realities and customer empowerment.

In our experience, there are four key drivers of a move toward product-centric model:
- Digital Core – to evolve, innovate as well as leverage cloud, DevOps and agility to support the business.
  - DevOps practices and agility from ideation to sunset.
  - Encourage innovation.
  - Digital ready systems.
  - Focus on Product value.
  - Lean planning and maintenance.
- Intelligent Enterprise – to optimize the cost and delivery of services and encourage innovation.
  - Automation to support business agility of the power utility.
  - Autonomous operations to support power distribution and customer management.
  - Decisions based on insights drawn from customer and market data.
  - Focus on the innovation of products, services offered and customer engagement.
- Experience Quality focused on improving customer experience.
  - Product centric service delivery.
  - Business agility.
  - DevOps practices.
  - Experience centricity.
  - Product and experience-focused metrics.
  - Command center that is aligned with the business.
- Service Management and integration for scalability and unification of service delivery in the power utility while retaining a multi-supplier ecosystem as needed.
  - Continuous improvements.
  - Standardized deployment and integration management.
  - Collaboration in a multi-supplier scenario.
  - Service lifecycle management.
  - Information technology service delivery performance management.
This transformation to a product-centric organization ensures that processes, people, workflows and decisions power the power utility’s ability to:
- Customize services and offers.
- Improved and faster response to customer requests.
- Consistent and distinguished cross-channel experience for customers.
- Boost productivity.
- Eliminate waste.
Shifting to a Product-Centric Model

The product-centric model of delivery uses Agile, DevOps and Lean principles for strategic planning to ensure uncertainties and lack of information do not derail the delivery of services to end customers. A product-centric model places importance on relatively shorter horizons of budget and effort planning over massive planning at the beginning of a financial year. This is important, as a power utility is likely to be able to plan better for a quarter at a time rather than a complete year, particularly in the current economic climate. This not only ties well with the goal of business agility but also ensures improved planning and budgeting, as there is more information available about business goals a quarter at a time. The new teams organized around business capabilities, as shown in Fig. 2, then plan the product backlog, execute, test and deliver business value
to business and customers continually.

Fig. 2: Shifting from technology to business-aligned value streams or product-centric organization

Power utilities also need to change and improve their technology-centric solutions to help with forecasting and data analytics. The product-centric organization helps with this goal by identifying gaps for closure and aiding the creation of self-organizing teams that then take on the goals of the organization to address all the identified gaps, including in areas of forecasting and analytics.

Fig. 3: Organization design – a product-centric organization

Fig. 3 shows a sample organization design for the product-centric model. The figure also shows the breakdown of the structure from business function to value steams to products or product groups and, finally, applications delivering value—all the while ensuring that the goal of customer-centricity is at the center of every decision.

Governance and Metrics

A very important part of creating and adopting a product-centric model of functioning at a power utility includes focusing on the governance of the transformation process, as well as business results accrued from the transformation. The acceleration and adoption of Agile and DevOps practices on the technology side can be tracked through qualitative adoption measures. This leads to product level performance improvement, resulting in better products and faster delivery, with the product delivery mindset focusing on customer-centricity, leading to trends in:
- Faster time to market.
- Improved business satisfaction.
- Improved quality.
- Reduced information technology cost.
Other than this, following metrics and measures be focused upon:
- Adoption Measures.
  - Adoption maturity.
  - Competency/skill index.
  - Operational excellence.
- Product Team Level Measures – measured at team level per sprint.
  - Productivity measures such as team velocity and throughput.
  - Stakeholder satisfaction measures such as product owner demo satisfaction.
  - Quality measures such as percent automated unit test coverage and test effectiveness.
  - Business effectiveness measures such as business value delivered per feature and requirement readiness cycle time.
- Product Group Level Measures – measured at product family level per month or quarter.
  - Lead time to change.
  - Cost of requirement change.
  - Release frequency.
  - Cost of rework.
  - Mean time to recover.
  - Application stability.
- Portfolio Level Measures – measured at portfolio level per quarter or half-year.
  - Delivery satisfaction index.
  - Customer satisfaction index.
- Team Satisfaction Metrics.
  - Team happiness index.
- Coaching Effectiveness.
  - Coaching feedback.
- Team’s Self Organization Quotient.
  - Product ownership.
  - Sprint health.
  - Team health.
  - Technical health.
Potential Areas of Benefit for a Power Utility

There are at least four core areas in which a power utility can expect to experience quantifiable benefits by transforming to a product-centric model of operations. They are:
- Budget and Plan
  - Cost and time are the most valued commodities in a tightly run power utility.
  - A product-centric model ensures money, effort and time are allocated based on the validation of investment already made in an initiative.
  - Improvement in prediction of timelines, effort and benefits of an initiative because of cadence and timeboxing inherent to the product-centric model.
- Managing the Capacity
  - The key focus is on alignment with business and continuous delivery of business value.
  - The cost of delay and the cost of waiting are also reduced.
  - Focus on value delivery with quantified business benefits.
- Governance of Programs
  - The governance in product-centric organizations is about the exercise of control on the quantification of benefits.
  - The focus in a product-centric organization is on “building the right things the right way.” Rationalization of cost, elimination of waste and focus on business value are direct by-products.
- Managing the Demand
  - Continuous visualization and management of demand is an area where benefits are accrued as needs and ideas flow into the strategy filter continually from several sources.
  - The product-centric model allows the continuous elaboration of light use cases to ensure value is correctly calculated and assigned to each use case.
  - The program, portfolio and product backlogs are continuously evaluated to ensure that there is a cost-benefit sense to each item.
Conclusion

Some of the benefits of a product-centric model usage at power utilities are stated below:
- Customized electricity plans for efficiency, cost or comfortable consumption.
- Improvement in reliability.
- Creation of environmentally sustainable renewable programs of power for the more aware customers.
- Incrementally move toward a “business as usual (BAU)” relationship with regulatory changes.
A product-centric model at power utilities can also help bridge the data divide to improve data and analytics usage and enable creation programs in the following areas:
- Services and products that the customers are most probable to use.
- Optimized collection and prediction mechanisms to create plans to encourage timely payments.
- Create pre-paid services.
- Plans for direct control of load which allowed the utility to reduce air conditioning kind of machinery during peak usage and in return recompense customers.
- Improve pattern recognition for delinquency and fraud management.
- Cross-selling opportunities.
- Targeted sales and marketing campaigns.
This article was co-authored by Anurag Choudhry, Enterprise Architect, Manufacturing & Utilities BG at Tata Consultancy Services.

— Anshu Premchand
August 3, 2020
DevOps Chat: Software-Defined Storage, With StorPool

The whole Data/DataOps space is becoming very hot. For StorPool, it is more of a case of the rest of the world catching up to what the company has been doing for a while now. It is the leading distributed block storage provider globally.

In this DevOps Chat, we speak with Boyan Krosnov, co-founder and chief of product at StorPool. Boyan gives us the background on StorPool as well as a good look at the state of the distributed storage/data market.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

DevOps.com · Storpool software defined storage

Transcript

Alan Shimel: Hey, everyone, this is Alan Shimel. You’re listening to a DevOps Chat here on DevOps.com, and my guest in this DevOps Chat is Boyan Krosnov from StorPool.

Boyan Krosnov: Hi, Alan.

Shimel: Boyan, I know it’s not perfect, but it’s the best I could do with your name, I apologize. But why don’t you say it for our audience?

Krosnov: Sorry—repeat, please? I did not hear.

Shimel: Why don’t you say your name for our audience?

Krosnov: Yeah, so, my name is Boyan—Boyan Krosnov, but in, kind of for English speakers, most people say Boyan Krosnov, like, with the stresses at the wrong places, but it’s perfectly okay, you know, I understand.

Shimel: As long as they don’t call you late for dinner, as we say here, right?

Krosnov: Yeah, okay.

Shimel: So, Boyan, your company is StorPool, yes?

Krosnov: Yeah.

Shimel: And what’s your position with StorPool?

Krosnov: In StorPool, I am one of the Co-founders, one of the three Founders in the company, and my role as a Co-founder from the very beginning has been kind of the glue between technology and business and the product person in the company, the Chief of Product of StorPool.

Shimel: Sure.

Krosnov: And the other two Co-founders, you know, respectively take, are focused on technology development and the other Co-founder on strictly business, who is our CEO, right.

Shimel: Someone has to do that. Okay.

Krosnov: Someone has to do the business stuff, yes.

Shimel: Someone has to. Before we jump in, Boyan, to what StorPool is about and what you guys do, why don’t we talk a little bit about your own personal journey? How did you come to found StorPool? What’s your background?

Krosnov: Yeah, right. So, back in the ‘90s, I used to do competitive programming, so like, from a fairly early age, I got very interested in informatics or computer science, right? And from that, later on, I went into networking and ISPs, later on, I had a startup around something called packet processing and nowadays software-defined networking.

And from that, at the later stages of that startup before we folded that, we found this gem of an idea of software-defined storage before it was called software-defined storage, right? So, we didn’t know it was called software-defined storage; the term wasn’t coined yet. That’s, like, in 2011.

Shimel: Mm-hmm.

Krosnov: And, from that, we founded StorPool. So, I got with the other founders and did, like, a whiteboard exercise of what an ideal storage system would look like. And that became the architecture of our product afterwards and we’ve been building on that for the last years, right? It’s eight years now.

Shimel: Yeah.

Krosnov: And along the way, we got—yeah, so, I’ve lived in a few places, not just in Bulgaria. I’ve lived in Iceland and the U.K. and Malaysia and a few others. And so, in StorPool, you know, we started with the idea, implemented it, got it to first production use some five, six years ago, right, and since then, we’ve been expanding it in a very kind of real business organic way, meaning pretty high growth, but at the same time, very customer-oriented. So, it’s very—the things we build into the product are things that our customers demand, right? It’s not like a completely greenfield.

Shimel: Yeah, everyone already has some data.

Krosnov: We do stuff that matters for our customers, right?

Shimel: So, Boyan, listening to your story, I’m reminded of my own. You know, I got into technology in the mid-‘90s when the web first started coming in, it was just starting to get commercial, and we were storing websites. It wasn’t called hosting. I thought I was a virtual real estate person, [Laughter] because as I needed more land, I put another hard drive in the machine, right?

Krosnov: Yeah.

Shimel: And by about 1997, people started calling that web hosting.

Krosnov: Yeah.

Shimel: And we sold the company in 1998, we ended up doing a whole IPO and that whole thing. But, you know, at the end of the day, what we were doing is, we were just, we were storing people’s websites. I was selling virtual real estate, renting virtual real estate out. And it sounds like a similar thing you, before there was a thing called software-defined storage, you recognized that there was a need in the market for people to do, to be able to store stuff without the expensive, I mean, you know, back—I remember in those days buying EMC boxes, right?

Krosnov: Yeah, yeah.

Shimel: And some of the Sun and IBM—was it IBM Sharp? I forget. But all of these huge SAN—you remember the days.

Krosnov: Yeah.

Shimel: Millions—millions of dollars in SANs and all of that. And then, [Snaps fingers] it was like a flip—like a switch flipped. People started saying, “Wait a second, we could do this in software, for a lot less money with a lot more advantages.”

Krosnov: Yeah, yeah.

Shimel: And it sounds like StorPool happened to be right there at the right time when this was coming together.

Krosnov: Yep, so, kind of the reason we started it was a few conversations with, actually, hosting companies.

Shimel: Really?

Krosnov: Actually hosting companies and some banks, but it started with hosting companies, and at that time, there was this big movement in hosting—everyone wanted to be the next DigitalOcean, right?

Shimel: Right.

Krosnov: Everyone wanted to have, like, a public cloud service with virtual machines and be like Amazon and DigitalOcean. And there were architects in these companies that were trying to figure out how to do it and they couldn’t and the one piece that was missing was software-defined storage. It was, like—they couldn’t make the business model work with standard SAN from HP or IBM or EMC, right? And we had to find a solution that worked for them which runs on standard servers—like, it’s not a proprietary box.

Shimel: Understood, understood. So—I mean, but that was 2012. Now, here we are, 2020. Software-defined storage is a much better-understood term.

Krosnov: Mm-hmm.

Shimel: You know, I think it’s gone mainstream, if you will, right? People understand it and use that.

Krosnov: Yeah.

July 23, 2020
State of Software Delivery Management Report 2020
Accelerated Strategies Group conducted the State of Software Delivery Management 2020, surveying software delivery practitioners and key industry leaders to assess the current state of software delivery management (SDM) and examine the impact of SDM adoption as a capability. The primary research, commissioned by CloudBees, was published on Tuesday, July 21.

The State of Software Delivery Management Report 2020 defined SDM as “a core competency for any organization or team responsible for delivering business value via software applications and systems.” The report studies the impact of SDM and how it helps organizations accelerate their digital transformation by providing the necessary tools to effectively and efficiently deliver software.

The report identified three key SDM capabilities to help organizations increase their software delivery efficiency and effectiveness:
- Organizations must quantify the impact of their investment in software delivery.
- Organizations must enhance the ability of software delivery teams to communicate and collaborate.
- SDM can provide end-to-end visibility into the value flow of their software delivery streams.
Based on the results of the research, adopting SDM strategies can help mitigate major challenges faced by software delivery practitioners, IT management, product stakeholders and executive leadership, and improve an organization’s ability to deliver software in a lean and agile manner. SDM capabilities provide businesses the ability to effectively make decisions on where in the value stream to invest, and to quantify the impact of their investments.

Download the State of Software Delivery Management 2020 to learn more about SDM and to get insights and access to all the data Accelerated Strategies Group gathered from one-on-one interviews with key industry experts.
July 21, 2020
How No-Code Software Development Speeds Digital Transformation
More organizations are democratizing software development through no-code solutions that empower anyone to write applications

In today’s fast-paced and digital business world, organizations must revise their goals and processes to achieve digital transformation and remain a viable business.

However, most transformation efforts fail. Recent McKinsey research shows that 70% of complex, large-scale change programs don’t reach their stated goals. For most organizations, the complexity of the technology environment and the inability to swiftly implement necessary changes are major roadblocks.

No-code solutions allow organizations to stay agile and accelerate their strategy execution by empowering power users (or business users) and developers to rapidly develop applications. Such solutions also improve the ability of IT to respond to business demands, shorten time-to-market and accelerate digital transformation.

What Is a No-Code Solution?

A no-code solution mitigates the need for manual programming in application development. Instead of writing lines of code, users can develop applications through simple point-and-click on specific components that can be arranged into logical sequences to create functional and feature-rich applications.

The inherent value no-code software development is it accelerates and democratizes the application development process. With such a solution, your power users can build applications to solve critical business problems and automate tasks to increase productivity.

5 Benefits of No-Code Software Development Solutions
- Reduce the load on IT: As mentioned before, no-code solutions allow business users to build applications without any coding knowledge. By enabling such a change, the solution reduces the burden on the understaffed IT department. Applications to solve business challenges and increase productivity can be built quickly without relying on IT. This in turn allows the IT department to dedicate more time to business-critical apps and projects.
- Accelerate development time: No-code solutions enable business users to take application development into their own hands; they don’t have to wait for their requests to be answered by the IT department. Tasks that used to take months (even years) to complete can now be done in a few hours or days, depending on its complexity. That is the level of acceleration a no-code solution can provide to the application development life cycle.
- Ensure more targeted outcomes: The point-and-click configuration of no-code solutions empowers the business users and developers to quickly build solutions to meet their exact requirements and specifications. Such applications then can be updated on the fly. These aspects are important to keep the business competitive and agile. While a no-code solution allows the development of applications for immediate impact, it can also prove to be cost-efficient in the long run.
- Fight shadow IT: When the IT department is unable to act on the requests of business users, those users start seeking solutions on their own. With the rapid rise of SaaS, they can quickly find an application to meet their needs. However, adopting such applications can lead to security vulnerabilities. A no-code solution enables businesses to eliminate the problem of shadow IT by allowing the business (power) users to develop their solutions to meet specific business needs while enabling IT to centrally control the data and user accesses.
- Enable experimentation without risks: Experimentation is an essential part of digital transformation. No-code solutions allow organizations to test their ideas on a small scale to eliminate the setbacks. It empowers business users to experiment with their ideas, iterate projects efficiently and create solutions that can transform organizations and keep them adaptable to changes in the industry.
To meet the challenges of digital transformation and remain competitive in the marketplace, organizations need to create an environment that enables agility and flexibility of the internal workflows and customer-facing operations. When powered by a comprehensive no-code solution, organizations can create an infrastructure that allows them to transform and innovate faster, which generates new growth opportunities and provides a competitive advantage.
July 7, 2020
Businesses Modernizing Apps in Wake of Pandemic

A survey of 5,000 business decision-makers, IT decision-makers and app developers published suggests organizations are taking advantage of the crisis created by the global COVID-19 pandemic to accelerate the modernizing of apps using DevOps practices.

Conducted by the market research firm Vanson Bourne, the survey finds 80% of respondents said organizations must modernize the technologies they use to develop and deploy software to be more successful. Nearly as many (79%) said their organization will not be able to deliver a best-in-class end user experience without successfully modernizing software development processes.

In addition, 80% of respondents said embracing developer processes such as test and learn would enable organizations to work more effectively and efficiently.

The survey also finds some organizations are not letting a proverbial good crisis go to waste. A total of 70% said they have good or excellent alignment between application development and IT teams, up from 64% prior to the pandemic. Alignment between business teams and application development (67%) and IT teams (67%) increased by 10% and 12% respectively since the start of the pandemic, according to the survey results.

Sumit Dhawan, senior vice president and chief customer experience officer for VMware, said the need to make applications more accessible and reliable is accelerating a transition to the cloud. The survey finds the primary benefits of modernizing apps are enabling remote workforces (54%); pushing quick updates in response to changing landscape (42%); and maintaining reliable uptime (41%).

The scope of application modernization initiatives varies widely. Some organizations are simply lifting and shifting existing application workloads along with the virtual machines they run on into the cloud. Others are refactoring applications to run natively on a different virtual machine platform provider by a cloud service provider. Others are wrapping existing applications in containers so they don’t have to be refactored when deployed on another virtual machine. Still others are employing containers and Kubernetes to develop entirely new microservices-based applications that tend to be more flexible and reliable than existing monolithic applications.

Regardless of the path forward, the inability to physically access local data centers during the pandemic has accelerated a shift to the cloud that was occurring even before the pandemic hit. There still will be many applications that for performance, security and compliance reasons may need to remain in on-premises IT environments. However, it might not be long before IT organizations also modernize those applications to make them both more accessible, flexible and resilient.

Most IT teams will find themselves managing microservices-based applications alongside modernized monolithic applications for years to come. Over time, however, many of those monolithic applications will be deconstructed into a core set of microservices.

At the core of all those initiatives will be a set of best DevOps processes that each IT team defines for itself based on the nature of the application portfolio that needs to be developed, deployed, secured and maintained. The challenge now is determining which applications should be modernized versus simply replaced by either a software-as-a-service (SaaS) application or a custom cloud-native application that is a better fit for the purpose.

June 30, 2020
OpenLegacy, Boomi Simplify Legacy Application Integration

OpenLegacy, a provider of a platform through which application programming interfaces (APIs) are layered on top of legacy application processes, announced today an alliance with Boomi, an arm of Dell Technologies that provides organizations with access to an integration platform-as-service (iPaaS) that is made available as a cloud service.

Zeev Avidan, chief product officer for OpenLegacy, said the company’s core platform enables IT teams to convert legacy application processes into microservices that can be involved by tools such as Boomi using an API. Rather than merely providing access to an application, OpenLegacy is designed to capture all the business logic, metadata and associated middleware associated with a specific business process executing on, for example, an IMS or AS/400 platform, he said.

The Boomi alliance extends that capability to include processes created by either citizen integrators or developers via the Boomi cloud service. That’s critical because most mission-critical applications in the enterprise still run on legacy platforms. Rather than having to rewrite those applications from scratch, Avidan said OpenLegacy makes those applications more easily accessible to other applications and platforms via a software development kit (SDK) based on Java.

At a time when many organizations are looking to accelerate digital business transformation initiatives, Avidan said being able to programmatically invoke an entire business process accelerates the rate at which those initiatives can be completed because business processes don’t necessarily have to be re-engineered.

In the case of Boomi, that capability is now being extended all the way to end users to make it feasible to tap into existing business processes using a set of tools that already have been adopted by more than 11,000 organizations.

OpenLegacy is making a case for DevOps teams to think in terms of legacy business processes rather than individual applications. Historically, many organizations have relied on enterprise service bus (ESB) platforms to integrate applications. However, a DevOps team still has to manually integrate all the software components that make up a business process once application environments are connected.

Legacy platform integration in the absence of OpenLegacy becomes the digital equivalent of an archaeological dig, said Avidan, noting many organizations wind up hiring expensive systems integrators to accomplish the task.

In the wake of the COVID-19 pandemic, there is clearly a lot more interest in modernizing business processes. Many employees are working from home for the foreseeable future. Cloud services such as Boomi provide a means of enabling end users to craft workflows on their own. The challenge has always been finding a way to easily connect those workflows to transaction processing systems and other systems of record around which the business depends.

It’s not clear to what degree providing that level of access will drive a burst of business process innovation. However, DevOps teams that spend an inordinate amount of their time integrating new applications with legacy business processes might be keen to leverage an approach the promises to turn those business processes into a reusable microservice.

June 29, 2020
But Wait, There’s More! The Trouble With DevOps Tools

DevOps tools today increasingly are no longer out-of-the-box ready for use. And that’s an aggravating issue

Imagine you bought a new power tool—a sweet battery-powered drill/screwdriver that did everything you needed.

Imagine it looked as though it ran on its own, but when you got it out of the box, you discovered that it didn’t come with a battery.

Imagine you got the battery, and only after the battery was installed you discovered that it needed a specialized wrench/chuck to install and remove bits. And you had to go buy that.

Imagine you got the chuck and were all set to go, only to discover that it would slip and normal drill bits wouldn’t turn unless you had a specialized adapter.

That’s what our tools environment in DevOps has become. And we need to demand better.

If your software requires X and Y and Z to be useful—whether you are commercial or open source, whether X and Y and Z are a million bucks or zero—state it before install.

We’re setting up an entirely new environment, stretching things a bit for an internal project, and honestly, the amount of “Oh yeah, this is required, too” that we’re finding out after install is insane. We have done our research; we should not be getting surprised by “But wait! There’s more!” type installs.

For an industry that insists on plug-and-play for all OSes and every odd bit of hardware ever dreamed up, we sure let software steamroll us. Vendors need to be clear about what will be required to run the tool and what will be required to run it effectively before we waste our time. Because there are some dependencies we’re not willing to accept, for usability reasons and/or security reasons. And if, under the covers, the tool does exactly the same thing as another tool … then what, exactly, is the value-add? It better be good.

We’re just one DevOps group—and a small one at that—but we have decided for this project not to use tools that dupe us into thinking they’re usable out of the box, then immediately require us to install something else. Or at least we’re trying. This has gotten so prevalent that in a couple of areas, we’re struggling. After all, the software still has to be built.

It’s a good thing drill manufacturers don’t think that way. Maybe there is hope.

Meanwhile, we’ll keep trying to do what you all are doing: kicking rear and keeping systems running.

June 29, 2020
Microservices vs. Monoliths: Which is Right for Your Enterprise?
With microservices projected to grow globally at a 22.5% rate between 2019 and 2025, the choice between monolithic and microservices architectures needs to be carefully considered. If you are wondering what microservices are best suited for, or whether your business should stick to monolithic or switch to microservices, here are a few cardinal points to take into consideration.

What Is Monolithic Architecture?

A monolithic application is built on a single code base with a variable number of modules. The number of modules depends on the complexity of the business and its technical features. The whole application—and dependencies, when applicable—are built on a single system with a single executable binary for deployment.

A monolithic architecture has distinct advantages and disadvantages that should be evaluated when deciding when selecting the optimal type of architecture for the application.

Monolithic architecture pros:
- Fewer cross-cutting concerns: The majority of applications typically have a large number of cross-cutting concerns. Running them all on a monolithic architecture facilitates hooking up components.
- Less operational overheads: Avoids the additional costs stemming from microservices such as interservice communication, service discovery and registration, load balancing, decentralized data management or distributed logging, for example.
- Complex testing: Testing for microservices is considerably more complex than for monoliths.
- Better performance: As shared-memory access is faster than interprocess communication, a monolithic architecture typically has better throughput performance.
Monolithic architecture cons:
- Overly tight coupling: Entanglement increases the difficulty of isolating services for upgrades or independent scaling when the application evolves.
- More difficult to understand: As the application grows and the number of layers and dependencies increases, understanding the system becomes increasingly difficult.
- Slow build and test create releases: Upgrades imply recoding the entire application to factor in the dependencies and side effects.
- Hard to distribute development: Tightly integrated applications are difficult to break into chunks, which complicates the creation of a distributed team effort.
- Usually requires opting for a single programming language: Integrating more than one language in a monolithic application is fraught with challenges, typically preventing the integration of components written in a different language, which might limit the flexibility of adding features best suited to an external language.
- Complicates the adoption of third-party tools: Adding self-contained third-party components, for example, cloud-native, to a single code base with multiple dependencies requires complicated hookups to different layers of the monolithic application.
What Is Microservices Architecture?

Microservices architecture is designed to accommodate the need for large application development by providing a suite of modular components and services.

When considering what microservices are particularly well-suited for, the following advantages and disadvantages should be taken into account:

Microservices pros:
- Better organization: Microservices are organized around business and technological capabilities, in units that are independently deployable.
- Decoupled: Each unit can be independently upgraded without requiring a complete overhaul of the application.
- Performance: Flexibility in opting to privilege performance or flexibility as needed, including independently scaling heavily used services by isolating them from the remainder of the application.
- Fewer mistakes: The hard-to-cross boundaries between microservice units limit the technical possibility of generating mistakes, notably cascading ones.
- Easier onboarding of new developers: They only need to master the microservice unit they will work on instead of the entire application architecture.
- Scalability: Each microservice can be scaled independently, while also adding new components.
- Improved fault isolation: As modules work independently from each other, a failure in one module does not affect another.
- Elimination of vendor or technology lock-in: As each microservice module can be operated independently, replacing underperforming modules with better ones from an alternate vendor is relatively easy.
- Ease of understanding: As services are broken down into modules, understanding the functionality of a module is easy for developers.
- Smaller and faster deployments: Each service can be scaled independently as needed, instead of scaling the entire application. This can lead to cost savings.
Microservices cons:
- Cross-cutting concerns: Microservices require handling cross-cutting concerns such as externalized configuration, logging, health checks, metrics, service registration and discovery and circuit breakers, as well as those specific to the technologies used by the microservices.
- Higher operational overhead: Microservices deployment typically leads to an increase in the number of units and containers, increasing the management and operation cost overheads.
- Security threats: Microservices architecture presents an expanded attack surface. Securing a containerized application requires managing privileged access at image, container, node, pod and namespace levels, ensuring encrypted tunneling from ingress to egress and other elements that require baking in security from the beginning.
- Multiple complexities requiring management:
  - Communication between services on a technological level, and between teams on an operational level.
  - Selecting the optimal pattern from the several microservices patterns available.
  - Provisioning sufficient IPs.
  - Provisioning resources (memory, CPU, disk) to accommodate each cluster requirements.
  - Maintaining multiple programming languages and frameworks.
  - Handling the incompatibilities between existing tools and new service dependencies.
  - Accounting for automation tools for each service requiring individualized testing and monitoring.
  - Achieving data consistency between each service’s individual database and transaction management system.
  - Handling the number of processes that can grow exponentially when load balancing and messaging middleware are considered.
  - Provisioning for the increase in documentation overhead stemming from the need to keep schemas and interface documents up to date.
  - Refactoring of an application built on monolith architecture is a massive undertaking for large enterprise applications.
- Complicated global testing: Global testing requires that each dependent service be tested first. This can be partly assuaged with automated testing.
- Difficulty in debugging problems: Debugging requires inspecting each service log independently, increasing the workload.
- Deployment challenges: Microservices are written in a variety of frameworks and languages and require distinct resources, scaling and monitoring, making orchestrating the deployment challenging.
- Large versus small product companies: Though the benefits of microservices are invaluable for large companies, adopting a microservices architecture creates overwhelming complexities leading to slower implementation and unnecessary cost increases for small companies.
- Higher costs: Without careful and strategic planning, cloud service bills may balloon due to the increase in data stemming from intraservices calls and the increase in resource requests to account for scalability and lack of friction.
- Cultural changes: Microservices require the company to have an agile DevOps culture.
As microservices architecture provides a better way to manage growing data sets, leverage cloud storage and automation and deploy solutions fast, microservices are usually preferable to monoliths. However, they might not always be the best choice for an organization. Before opting for microservices, a careful examination of your company culture and business objective is imperative.
June 26, 2020
COVID-19 Long Tail Budget Impact

Technology budgets have shifted dramatically since the beginning of the COVID-19 pandemic, according to a recent study from online CIO networking and information hub, Pulse. The pandemic, and its resulting shutdown, will likely continue to have a substantial impact on technology budgets for some time.

The initial budgetary impact was substantial. When COVID-19 first arrived, many technology budgets were frozen in place. Today, 23% of CIOs report that their budgets are still frozen with 49% reporting a decline in their technology budgets. Seventeen percent said that they expect to decrease their budgets by more than 10% in the next two months.

Fortunately, it’s not all bad news. Many respondents, 24% of them, predict that within the next two months their budgets will rise, including 9% of respondents who believe their budgets will increase more than 10%. However, most CIOs (27%) say that their IT budget won’t change in the near future.

“And an additional 6% anticipate their budget will become frozen in the next two months — though, on a positive note, this figure is down from 23% two months ago,” stated the report.

Surprisingly, there hasn’t been a change in business-technology priorities over the past two months for 79% of respondents, while 21% said that they now have different priorities than from the beginning of the pandemic.

The priorities of those surveyed include focusing on internal communication and collaboration tools (45%), mobile security (39%), customer communication and collaboration tools (37%), password management tools (28%), virtual private networks (28%), security awareness training (24%), remote desktop tools (23%), encrypted communication tools (23%), and data security tools (15%).

“Many companies are going to allow (or require) employees to work from home after the pandemic, due to health concerns and reduced overhead. The fact that CIOs are investing in security and end-user technology — even though budgets are decreasing — indicates this,” said Brian Sampietro, CIO at TGI Office Automation, in the report.

For those organizations who changed their priorities, the new budget items include virtual private networks (36%), password management (32%), remote desktop tools (30%), data security tools (27%), encrypted communication tools (26%) and mobile security (21%).

How are CIOs making decisions when it comes to technology purchases? The majority said peer recommendations (69%) and industry analysts (52%). However, social media and email fared poorly as influencers, at 23% and 20% respectively. CIOs are determining needs, according to the survey, based on both executive and end-user requests. Only 10% said they depend upon user requests alone, and only 21% said executives solely drive decisions. Interestingly, 35% of CIOs make decisions quickly: Within one week they said they will decide on the right tool to acquire. The rest said they take more than a month (26%) or within four weeks (39%).

When it comes to layoffs, there are still rough patches ahead, as a sizable number of organizations still have layoffs on the planning table. While 48% of organizations have maintained their headcount through the COVID-19 crises, 40% do plan to cut staff sizes in the next six months, with 25% not sure if they will cut staffs.

June 23, 2020
IT Modernization Yields Business Benefits Even in Early Stages
In recent years, with the emergence of newer technologies ranging from the cloud to machine learning, IT modernization has evolved from a replacement of end-of-life infrastructure to an enabler of innovation and business value. It is a complex process that can take months or even years, but a recent survey shows that the effort begins to deliver measurable results almost as soon as an organization executes the first steps on its roadmap.

In The State of IT Modernization 2020, an IDG Research Services survey of 200 IT executives commissioned last December by Insight Enterprises’ Cloud + Data Center Transformation team, respondents that had completed 25% or less of their initial modernization objectives reported achieving business improvements in each of the eight categories measured. Sixty-five percent had already achieved better quality of service. Significant progress had also been made in improving customer experience/satisfaction (52%), cost savings (50%), uptime (44%) and the ability to create new revenue-generating products and services (42%).

Organizations that had completed their initial modernization objectives reported even better outcomes on all eight measures, notably including the ability to extract business value from data (56%) and faster time to market for new products and services (50%).

The findings clearly demonstrate that a modernized IT ecosystem is a core building block of business transformation. Whether it’s spinning up a new service or application quickly, doing a deep data dive to identify new market opportunities or using artificial intelligence to improve sales forecasts or warehouse operations, it’s essential to have the horsepower, agility and advanced data analysis capabilities to do the job.

The survey of CIOs, CTOs, CSOs and IT directors working at organizations with an average of 29,294 employees also revealed a wide range of details about the status of IT modernization efforts. Let’s look at some examples.

Progress Made

Fifty-six percent of the enterprises surveyed have either achieved initial IT modernization objectives or have made significant progress toward doing so, while 19% have made moderate progress and 26% are in the beginning stages. Interestingly, even those in the earliest stages are pursuing emerging technologies such as AI, machine and/or deep learning (43%), automation to support scale-out and other cloud strategies (37%), cloud native application development (35%) and public cloud container services (35%).

Projects Derailed

Despite this progress, the road to IT modernization can be bumpy. Forty-one percent of survey respondents reported having delayed or abandoned some of their 2019 IT modernization initiatives. The top reasons cited were competing priorities (46%) and lack of a clear roadmap or strategy (45%). Other causes included data security concerns (39%), inadequate in-house expertise (38%), poor preparation (29%) and outdated processes or tools (27%).

Shifting Cloud Strategy

Whether they have just embarked on their IT modernization journey or have made significant progress on their roadmap, organizations continue to grapple with optimizing their cloud strategy. The survey showed that:
- Ninety-two percent of survey respondents increased workloads deployed in the public cloud and 91% in the private cloud in 2019, reflecting the ongoing increase in cloud adoption as well as migration from one platform to another.
- Eighty-nine percent switched or planned to switch from an all-private or all-public cloud strategy to a hybrid cloud approach – and 87% adopted a multicloud approach using more than one public cloud provider – as they attempted to find the right path for their cloud needs.
- Eighty-four percent moved select workloads from a public cloud to an alternative cloud or non-cloud location, suggesting a failure to perform appropriate cost modeling, workload/platform alignment and other due diligence before the initial move.
Poor Public Cloud Cost Controls

More than two-thirds of survey respondents reported that public cloud costs exceeded their expectations, with cost overruns for roughly half that group ranging from 51% to 100%. Most of the causes can be traced to inadequate due diligence, governance or cloud optimization efforts, often due to a lack of in-house expertise in these areas. Examples include: unexpected data egress charges, subscribing to more cloud resources than required, failure to take advantage of vendor volume discounts, lack of knowledge to analyze monthly cloud costs and failure to optimize cloud workloads to extract maximum value from cloud platforms.

Managed Services

Adoption of managed services is widespread at every stage of the IT modernization journey, with an average of 95% of respondents outsourcing one or more IT operating environment functions to a managed services provider and 84% outsourcing cloud management.

Top Challenges Faced

Governance is the number one modernization challenge in 2020, according to survey respondents, with new strategies and processes required to ensure control over areas ranging from cloud deployments to continuous integration and continuous delivery (CI/CD), automation and orchestration, and infrastructure as code. Optimizing and managing the centers of data that are replacing the traditional data center ranks as number two, with workloads located on-premises and in multiple clouds as well as on the edge.

At the same time, most IT organizations have long-standing cultural and technological norms that need to change in order to move modernization initiatives forward. Hurdles cited elsewhere in the survey range from IT silos to outdated processes and tools, understaffed or underskilled DevOps teams and lack of enabling technology for containerization and automation.

These challenges also need to be overcome in order to take full advantage of today’s technology to drive innovation, business transformation and the competitive edge that can help businesses both survive and thrive in today’s economy.
June 22, 2020