It should be a break-down – not a break-up

Are microservices turning out to be the magic pill that they were heralded as? Or is it the classic case of ‘more pill than jam’ here?

It was supposed to be the slicer-knife that spared the pressure and sweat of boiling an ocean. How to make sure that the sharp and ingenious blade of microservices does not cut the enterprise’s fingers with more complexity, scale-issues and database snags? And can modularisation and orchestration help while not turning into extra headaches or investments. Allen Terleto, Field CTO, Redis Labs shares some blunt insights and interpretations with Pratima H, of a recent survey to address these doubts.

What is working in favor of microservices and what is not – specially in context of challenges like tooling, data management, troubleshooting etc.?

Microservices can be a game-changer for improved time-to-market and, more recently, transitioning to cloud-native operations. The architecture’s primary tenets of isolation, eventual consistency, empowerment of autonomous teams, and infrastructure automation are a perfect fit for incremental migrations from anchoring legacy technologies to fine-grained business services deployed on the cloud.

Keeping with the tenets of microservice architecture helps to avoid the pains felt by early adopters, however, also introduces new complexity as implementations scale to hundreds, or even thousands, of isolated components. In fact, according to an IDC InfoBrief survey which we commissioned, 35.8 per cent of respondents shared their concern for managing a large number of microservices.

This is where modern data platforms, such as Redis Enterprise, become a lifeline for organizations struggling to scale their microservice architecture. Redis Enterprise is a cloud-native, multi-tenant, multi-model, highly-performant, highly-scalable, highly-available, and highly-secure platform that can deploy on-premises, on the cloud, and/or container-based orchestration platforms.

In addition, Redis’ vibrant open-source community provides it with the advantage of ubiquitous ecosystem integrations and interoperability with tooling for orchestration, observability, security, automation, and more.

How crucial is the productivity-downtime problem that the IDC report unraveled – particularly when 24 per cent micro-service applications are business-critical?

Migrating an existing monolithic application to a microservice architecture comes at a cost and is not without trade-offs. Since enterprises expect a return on their investments, in many cases, revenue-generating applications are prioritized for migration. We see evidence of this in the survey, which states that “Microservices apps are already used in business-critical roles, with 24 per cent of microservices apps identified as business-critical”.

Naturally, business-critical services place a premium on uptime in terms of both availability and productivity. According to the survey, “For 42 per cent of microservices apps, experiencing downtime results in direct loss of revenue for the organization, showing the important role these apps already play in business.” Redis Enterprise’s cloud-native platform supports microservices with five-nines (99.999 per cent) uptime in Active-Active deployments.

Have microservices led enterprises into more complexity? Do they only work for cloud-native environments?

Complexity is a relative term that can apply at different levels of a solution. However, if we focus solely on the technical requirements of a microservice architecture, complexity is typically experienced at the data-tier. This is reinforced by the IDC InfoBrief survey, where 31.5 per cent of respondents agreed that “Database application development and management” was a top challenge.

Enterprises that limit microservices to green-field cloud deployments typically avoid common data-tier pitfalls since they primarily rely on NoSQL cloud-native databases. In fact, 84 per cent of the survey respondents claimed they use NoSQL databases to support their microservices.

However, since microservices aren’t just limited to the cloud, some enterprises attempt to leverage traditional databases for on-premises deployments. Since these legacy platforms were not designed for multi-tenancy, automation, and containerized-orchestration, their deployment becomes very complex, specifically at scale. Using a cloud-native NoSQL data platform, such as Redis Enterprise, reduces the complexity of on-premises microservices deployments and enables them for a seamless migration to the cloud.

What is your take on the idea of modularized monoliths?

Conway’s Law teaches us that an enterprise architecture mirrors its organizational structure which, in most cases, follows a traditional hierarchy with departmental silos. While these departments are typically composed of multiple teams, which work on individual software modules, their deployments are either coupled to each other or the same database. These monolithic dependencies between modules create the need for departmental release cycles, which are at the heart of stifling time-to-market and act as barriers to cloud migrations.

Contrarily in a microservice architecture, the monolith’s software modules are decomposed into fine-grained independently deployable services that can operate on their own release cycles. Conforming to Conway’s Law, small “two-pizza” teams can be organized around micro-subdomains, instead of departments, empowering them to make autonomous decisions and frequent software deployments.

Do event-based service approaches, use of a database strategy and orchestration tools emerge as good alternatives in light of the issues that microservices are manifesting?

Event-driven architecture, NoSQL purpose-built data models, and orchestration are at the heart of mature microservice architectures that are well-positioned for scale. Applying these same approaches to a monolithic architecture would not improve outcomes in terms of time-to-market nor cloud migrations.
Therefore, embracing these architectural principles as part of a microservice architecture would be more productive than to reinvent it.

How relevant are database decisions as per the report?

According to the IDC InfoBrief survey, 31.5 per cent of respondents cited database management as one of their top challenges along with a reported 47 per cent of microservices relying on a database. Larger enterprises indicated a relatively normal distribution of chosen database types with NoSQL, such as key-value, wide-column, and time-series, models standing out as clear leaders. In addition, over 95 per cent of respondents cited database type (model) or performance as key criteria by which they chose their microservice’s database.

These survey results reflect many of the reasons behind the growing popularity of Redis within microservice architectures. As a multi-model in-memory NoSQL database, Redis provides enterprises with both performance and model-variety without over-complicating their deployment architecture. By leveraging Redis Enterprise’s multi-tenancy, enterprises can deploy each data model in isolation without increasing database management complexity.

What is the future of microservice architectures in India?

As a global hub for application development, India will be a focal point from which microservices scale-out across IT architectures. Redis Labs has seen a rapid acceleration of microservices deployments across our Indian-based customers. With the pervasive adoption of the Cloud and increased investment into Digital, this architectural style will only continue to grow in popularity.

By leveraging cloud-native platforms, such as Redis Enterprise, Indian-based application development and DevOps teams will be equipped to break through the barriers of legacy technology stacks as they prepare for a growing wave of Digital Transformation and Application Modernization initiatives.