Migrating a monolith application into microservices with single sign on

Embark on a transformative journey from monolithic applications to the cutting-edge realm of microservices architecture. explore the savory solution of Uitsmijter, making the migration to OAuth-enabled single sign-on systems a delightful experience.

General Discussion  

The Path to Microservices: A Journey of Innovation and Empowerment  

In today’s fast-paced tech landscape, companies are continually seeking innovative ways to stay competitive and meet evolving customer demands. One of the most profound shifts capturing the attention of forward-thinking organizations is the transition from monolithic applications to microservices architecture transformation that revolutionizes the very core of software development, deployment, and maintenance, offering compelling reasons to embrace the future.

Scaling to New Heights  

A driving force behind the widespread adoption of microservices lies in the promise of enhanced scalability and performance. Traditional monolithic architectures treat applications as unwieldy monoliths, making it challenging to scale specific components independently. The inefficiency of this approach often results in over-provisioning and wasted resources. Microservices, however, introduce a level of granularity that empowers organizations to scale individual services in response to demand. It’s akin to a finely tuned symphony, where each instrument plays its part precisely, optimizing resource allocation and, consequently, enhancing overall performance. The outcome is that applications gracefully handle increased workloads and unforeseen traffic surges while delivering a superior user experience.

Unleashing Flexibility and Agility in Development  

The shift towards microservices isn’t solely about infrastructure enhancement. It’s a complete reimagining of how software is developed. Microservices foster flexibility and agility by breaking down applications into smaller, decoupled services. This modular approach empowers development teams to work independently on various services, significantly reducing the bottlenecks associated with monolithic development. The ability to work in parallel accelerates development cycles, resulting in a quicker time-to-market for new features and updates. Moreover, microservices remain technology-agnostic, allowing organizations to select the best tools for each service. This newfound agility harmonizes perfectly with DevOps practices, facilitating seamless automation and nurturing a culture of continuous integration and continuous deployment (CI/CD). The outcome is a more nimble and responsive development process, ultimately enhancing innovation and adaptability to ever-evolving business requirements.

The Transformation of Processes and Team Dynamics  

Transitioning from a monolithic to a microservices architecture isn’t just a technological evolution; it necessitates a fundamental rethink of processes and team structures.

Microservices reorient development efforts. In this brave new world, individual teams take ownership of specific services, overseeing everything from development and testing to deployment. This autonomy accelerates the development cycle, enabling teams to operate independently and concurrently.

Cross-functional teams become the norm in a microservices-centric landscape. These teams, composed of developers, testers, DevOps engineers, and even product managers, collaborate harmoniously to ensure the seamless operation of each service. Communication takes center stage as teams define service boundaries, APIs, and standards. Emerging roles like “Service Owners” emerge to oversee the health and performance of specific services, emphasizing a holistic approach.

However, this transformation isn’t without its challenges—robust tools, processes, and cultural shifts are essential. As organizations scale the number of services, managing growth while maintaining consistency becomes a delicate balancing act. Nevertheless, for those prepared to embrace change and invest in the future, the rewards of agility, scalability, and enhanced development processes are well within reach through the embrace of microservices architecture.

The Rise of Data Mesh  

Following the shift to microservices, the benefits became evident, and the reconfiguration of team structures into more autonomous and self-reliant units became the new norm.

What microservices are to applications, Data Mesh is to data. It represents an innovative approach to managing and scaling data within organizations, particularly within large-scale, complex data ecosystems. The Data Mesh concept heralds a paradigm shift in data management, aiming to make data more accessible, reliable, and scalable across different parts of an organization.

Data Mesh addresses the challenges organizations face when dealing with vast and intricate data environments. It seeks to dismantle data silos, elevate data quality, and empower domain-specific teams to independently manage and harness their data assets.

The Role of Authorization  

Returning to the concept of monolithic team structures, it’s worth noting that in the past, many organizations employed a centralized IT department responsible for managing all applications. This evolved into a more advanced DevOps team, facilitating collaboration and communication between development (Dev) and operations (Ops) within the organization. Their core objective: streamline the software delivery process, automate repetitive tasks, and cultivate a culture of continuous integration and continuous delivery (CI/CD).

Yet, a fundamental perspective shift occurs when we consider the needs of individual teams taking ownership of specific services. The traditional model, where a centralized DevOps team deploys software for the development team, may no longer align with this new paradigm. The modern DevOps philosophy proposes a different approach: the DevOps team should not be the entity responsible for deploying the software. Instead, their role should evolve into one that empowers other teams by providing exceptional tools and robust support to enable autonomous software deployment.

Enter the Authorization Server a critical component in the realm of modern software applications, especially those embracing microservices architecture. It assumes responsibility for managing and enforcing access controls, ensuring that only authorized users or services access specific resources or data. In the context of DevOps and microservices, the Authorization Server becomes an integral part of the security and access control framework.

By empowering individual teams to manage their deployments and access control policies, the DevOps team can collaborate effectively with the Authorization Server team to ensure seamless integration of security and access control mechanisms. This collaboration guarantees that as new services are independently deployed, they are also appropriately secured, and access is managed consistently and reliably.

In essence, the Authorization Server, alongside the evolving DevOps philosophy, enables organizations to strike a balance between agility and security. It ensures that the autonomy and empowerment of individual teams do not compromise the integrity and confidentiality of sensitive data and resources. This progress advances an organization’s journey toward a more streamlined and efficient software delivery process.

This transition to greater autonomy is only feasible when service teams possess the ability to manage application settings independently. This autonomy allows them to respond swiftly to changing requirements, configuring clients and tenants to align with their specific use cases. This agility is pivotal for delivering features and updates promptly, ensuring that security and access control remain robust and well-maintained.

As the tech landscape evolves, Uitsmijter steps in to fill the gap that modern, self-organized service teams face—controlling the complete lifecycle of services and data while enforcing access management. Uitsmijter ensures that users moving between different products developed by various service teams are controlled by the global ACLs that each team commits to.

With Uitsmijter, teams gain the ability to deploy clients and/or tenants in their own namespace while enforcing global security standards. This harmonious combination of autonomy and security empowers teams to take charge of their development while maintaining the integrity and confidentiality of data and resources.

Facing the problems of an application migration path  

Monolithic applications with their own login have one or more of the following factors in common:

• own, per application different kinds, of user authentication
• user data is stored in the applications database
• users usually have an internal ID, generated by the database (auto-increment)
• With this ID further fields from other database tables are linked

This results in the problem that removing the user authentication would entail a complete redesign of the application. Moreover, many authentication systems demand the migration of user data to their dedicated user repositories, complete with their unique sets of rights, roles, and profiles. These can be substantially different from the existing database structures. When transitioning from an internal login system to OAuth, not only does the user handle change, but it also triggers alterations within the internal structures of the application and impacts all database connections. However, with Uitsmijter, these challenges can be circumvented. We will now explore a straightforward method for achieving this.

To enable the conversion of monolithic applications, which originally have their own login systems, to process an SSO handle from external sources, users typically need to be migrated to an external system for most procedures. Traditionally, this migration process involved several test runs, often conducted during batch processing at night, especially when the implementation was not yet complete. Subsequently, the old application had to be entirely replaced by the new implementation in a single significant transition (Big Bang). Unfortunately, this approach frequently resulted in errors and application failures. However, with Uitsmijter, the transition of an application can be achieved progressively and while it’s in operation, all without any downtime. We’ll delve into how this works shortly.

Previously, when monolithic applications shifted from custom login systems to OAuth, they had to grapple with the complexities of OAuth in its entirety. This conversion was—and still is—a monumental task that consumes considerable time and resources. However, we’re about to unveil how Uitsmijter can simplify this process dramatically, making it an ideal fit for modern, Sprint-based development methodologies.

When all these issues are combined (and so far, we’ve only discussed user-related concerns), it leads to a prolonged, perilous, and intricate migration process. Many companies hesitate to undertake this migration, thereby delaying their transition to a microservices architecture—a change that could significantly boost productivity for the vast majority of organizations. Uitsmijter offers a solution—a software and accompanying guides that make migration secure, well-planned, agile, and, most importantly, enjoyable for developers and project owners. Its transparent and intelligent approach makes it a standout choice for navigating the complexities of this transformation.

Prepare an Interceptor first  

The Interceptor mode of Uitsmijter is primarily designed to secure individual web pages behind a login. Many users employ this mode to protect HTML pages (for instance, within an intranet or a closed client area) or to implement metering and a paywall to monetize editorial content.

While the Interceptor mode is well-suited for these purposes, it possesses features that can significantly aid us in the migration process and should not be underestimated in terms of its capabilities.

Internally, Uitsmijter employs the same mechanisms and externally presents two modes: OAuth and Interceptor. Internally, it is essentially the same, and an application protected through an Interceptor can easily be secured with an OAuth client. An application whose authentication is protected via the Interceptor mode can be enhanced by OAuth microservices that also recognize the user (SSO). This is precisely what we aim to achieve during the migration process: initially, we transition the monolith’s login, allowing us to gradually extract individual parts of the application as microservices.

By following this approach, we can break down the entire migration into manageable units, modernizing the infrastructure step by step. Moreover, with each iteration, we can continue to work on additional features. No Big Bang, no risks, no downtime.

As described, the simple Interceptor mode is indeed the ideal initial step to authenticate users through Uitsmijter before we proceed to externalize specific aspects.

A project demonstration  

To keep things simple, we use an easy ToDo-App to explain what is needed to migrate from a monolith to a microservice architecture with Uitsmijter. The full process is described in the documentation section. The example projects are in GitHub:

• ToDo application This app demonstrates a simple ToDo page before and after migrating authentication to Uitsmijter.
• CheckCredentials This service takes credentials from an Uitsmijter provider and validates it against an existing user database from the demonstration ToDo application.