Neel Shah, VP Software Development
April 22, 2024

At Strasz Assessment Systems, we initiated a cloud migration project for the AICPA Exams Team’s internal systems. Throughout this transition, we focused on using Azure’s cloud-native technologies to revamp our architecture. This post explores the significant architectural changes and highlights our strategies for planning, executing, and optimizing the migration process.

The Current Architectural Landscape

Our existing on-premises setup consisted of a mix of traditional and distributed systems managing various aspects of item banking, assembly, and result processing. These systems communicated through event-driven methods, utilizing messaging platforms and frameworks. Despite its robustness, we recognized the need for the greater agility, scalability, and innovation that a cloud-native approach provides.

Understanding Software Architecture

Monolithic Architecture

Traditionally, software was designed in a monolithic architecture, integrating all components into a single codebase.

Service-Oriented Architecture (SOA)

SOA deploys software components as services to build business applications, focusing on full business capabilities.

Microservices Architecture

An evolution of SOA, microservices architecture divides functionalities into smaller, task-specific components, enhancing scalability and flexibility.

When to Avoid Microservices:

  • Small or Simple Projects: If your application is small or lacks complexity, microservices can introduce unnecessary overhead.
  • Limited Resources: If your team lacks the expertise or resources necessary to manage a distributed system effectively, microservices can be challenging to implement and maintain.
  • Development and Operational Overhead: Microservices require robust DevOps practices and sophisticated tooling for monitoring and managing multiple services, which can be costly and complex.
  • Rapid Prototyping: For quick development cycles like MVPs or prototypes, the setup time for microservices can hinder speed and flexibility.
  • Frequent Changes: In environments with highly dynamic requirements, the complexity of coordinating changes across multiple services can slow down development.

Adopting Microservices

The migration to Azure provided us with the opportunity to re-architect our core systems using a microservices architecture. We selected this architecture specifically for its ability to create well-defined boundaries in our complex system. With microservices, each service can be developed, deployed, and scaled independently. This makes our system easier to manage and more adaptable to changes.

However, there are several key considerations to keep in mind when choosing this path:

Service Decomposition

In microservices architecture, each service operates independently with its own data and resources. These smaller, loosely coupled services offer significant advantages in flexibility and resilience. However, unplanned and haphazard service additions can create a tightly coupled system with excessive dependencies, negating these advantages. Thus, it’s crucial to implement effective strategies to define service boundaries.

Approaches to Define Service Boundaries:

  • Use Domain-Driven Design (DDD): Apply DDD principles to define bounded contexts within the business, helping identify which functionalities should be grouped based on cohesiveness and data management.
  • Analyze Business Capabilities: Align each service with a single business function, ensuring modular design and encapsulation of necessary functions to execute one complete business task.
  • Apply Conway’s Law: Align service boundaries with the organizational structure to facilitate system design and communication.
  • Decouple Based on Volatility: Services should be decoupled enough so that changes in one service require minimal to no changes in another. Analyzing how different components change over time can provide insights into how they should be separated.
  • Analyze Data Ownership: Design services around data ownership to ensure data consistency and integrity. Each service should manage its own database to avoid coupling through shared data sources.

Data Duplication

In microservices, each service managing its own data often results in some data duplication across services, allowing each service to operate independently. Although this adds complexity, it is generally accepted as necessary for the benefits of decoupling and enhanced agility.

Synchronous Calls

Relying on synchronous communication between services can lead to several issues:

  • Coupling: Synchronous calls can tightly couple services, making them dependent on each other’s availability and response times.
  • Performance: Waiting for responses in real-time can negatively impact performance, as the slowest service can become a bottleneck.
  • Complexity: Managing synchronous interactions increases the complexity of error handling, as each point of communication can potentially fail.

Microservices architectures advocate for asynchronous communication patterns wherever possible, which helps build more robust, scalable, and maintainable systems. Messaging frameworks such as NServiceBus, RabbitMQ, ActiveMQ, Apache Kafka, Amazon SQS, Azure Service Bus, and Google Cloud Pub/Sub provide scalable solutions supporting asynchronous communication.

Migration Phases

At a high level, our migration effort to Azure was structured into four key phases, which were staggered rather than sequential, allowing for flexibility and overlap where necessary:

Phase 1: Planning and Assessment

  • Inventory and Dependency Mapping: We obtained a detailed inventory of our system’s components, dependencies, and external integrations. This step was crucial for understanding the complexity and interdependencies of our on-premise setup.
  • Cost-Benefit Analysis: We evaluated the costs associated with migrating to Azure, including operational and maintenance expenses, against the benefits of cloud-native features like scalability, managed services, and reduced hardware costs.

Phase 2: Selecting Technologies and Foundations

  • Choose the Right Azure Services: We selected Azure services that best fit the needs of our system components. For example, NServiceBus for the messaging framework, Azure Service Bus for Pub/Sub, Azure Functions for Serverless Compute, Cosmos DB for data needs.
  • Data Migration Plan: We developed a detailed plan for migrating our data, considering factors like data volume, downtime, and data integrity.
  • Security and Compliance: We implemented Azure security features, including Azure Active Directory for authentication, Azure Key Vault for secrets management, and Azure Policy for governance.

Phase 3: Implementation and Testing

  • Environment Setup: We configured our Azure environment according to the planned architecture, ensuring all Azure services were correctly set up and integrated.
  • Embrace DevOps Practices: We adopted Azure DevOps practices to streamline our CI/CD pipelines, improve deployment frequency, and enhance system reliability.
  • Migrate and Refactor: We migrated our system components to Azure, refactoring as necessary to optimize for cloud-native characteristics.
  • Rigorous Testing: We conducted comprehensive testing, including load testing and security testing, to ensure that our system was resilient, secure, and performed well in the Azure environment.

Phase 4: Optimization and Continuous Improvement

  • Monitor Azure Infrastructure: We used Azure Monitor and Application Insights to track performance and health, continuously optimizing the system.
  • Monitor Message Flows: We employed NServiceBus tools like ServiceControl, ServicePulse, and ServiceInsight for detailed oversight of message flows and system communications.

Conclusion

Migrating to Azure presented a technical challenge and an opportunity to boost scalability, resilience, and efficiency. With careful planning, execution, and continuous improvement, you can ensure a successful transition and take full advantage of cloud-native features.

About the Author

Neel Shah is a seasoned technology leader passionate about driving innovation and delivering exceptional software solutions. As the Vice President of Software Development at Strasz Assessment Systems, Neel brings a wealth of experience in leading high-performing teams, shaping strategic initiatives, and fostering a culture of excellence. With more than two decades immersed in the technology sector, Neel has developed a deep understanding of distributed systems and Service-Oriented Architecture. This expertise enables him to spearhead the creation of scalable, resilient software solutions tailored to meet the dynamic needs of clients and stakeholders, underpinned by pragmatic technology choices. By fostering a culture of innovation and continuous improvement, Neel empowers teams to push the boundaries of what’s possible and deliver impactful results that drive business growth. In his leisure time, Neel enjoys quality moments with his wife and two boys, playing cricket, watching movies, and staying updated on the latest developments in science and technology.

John DeFalco, SR Software Engineer
August 6th, 2021

Ken White is a Scrum Master for one of our Agile development teams. He’s also our Production Support Operations Manager for the same customer. I don’t believe combining these roles is a practice unique to Strasz. What really sets Ken apart from most others is, he is also currently the Fire Chief for the Liberty Corner Volunteer Fire Department1. So, it goes without saying that Ken has both an educational background and practical experience to bring teams of people together with a high likelihood of success. We’ve all heard of the chicken and egg paradox. So was the fire department the chicken and his college degree the egg? Or vice versa?

Ken (left) alongside the Chief (middle) and Deputy Chief (right) of the Liberty Corner Volunteer Fire Department.

Ken White is a Scrum Master for one of our Agile development teams. He’s also our Production Support Operations Manager for the same customer. I don’t believe combining these roles is a practice unique to Strasz. I’m sure there are plenty of other leaders in the field that are holding down both positions. What might be rarer, Ken has a degree in Management Information System & Operations Management that almost exactly aligns with his current job responsibilities. What really sets Ken apart from most others is, he is also currently the Fire Chief for the Liberty Corner Volunteer Fire Department1. So, it goes without saying that Ken has both an educational background and practical experience to bring teams of people together with a high likelihood of success. We’ve all heard of the chicken and egg paradox. So was the fire department the chicken and his college degree the egg? Or vice versa?

James Lipton from The Actor’s Studio is often fond of saying, “Let’s start at the beginning.” Back in the summer of 1986, Ken was working as a lifeguard and snack bar manager at a local pool when a friend approached him about joining the volunteer fire department. He hadn’t previously given it a thought. Yet, he immediately became fascinated by the inner workings of how the organization came together as a team. He was impressed that such a large group of volunteers could be coordinated to achieve great things in the community. The do-it-yourselfer in Ken was also fascinated with the department’s dizzying array of tools and equipment. 

Later that same year, he went off to college at the University of North Carolina at Greensboro. Ken conveys his choice of UNCG simply as “My parents could afford the school, and it was farther away than Rutgers.” As was previously stated, he pursued a degree in Management Information Systems & Operations Management, which was a natural choice, in retrospect. From early adulthood, Ken had a predisposition towards organizational thinking, technology, leadership, and management.

After graduating from college, Ken began his career at AT&T as a software developer and simultaneously became more involved with the fire department. He started his coding journey with an internal COBOL development program at AT&T. Ken rose through the organization over the next ten years. Ken eventually became a District Manager, with a staff of 80+ and 3 direct report managers. Concurrently, he rose through the ranks of the fire department. He became President, then worked his way up as Assistant, 2nd Assistant, then eventually Chief. At the fire department, Ken leads a multi-faceted team of 60 volunteers. 

The overlap of these two paths is significant. Both have a business and support side that require intense management, efficient organization, and experienced leadership at a high level. A software company’s business revolves around planning and scheduling releases, conducting regular status meetings, managing budgets, and interfacing with customers. The fire department is organized as a not-for-profit business and, as such, has a President that presides over the company’s business. This includes filing tax for

ms with the state, managing donations, fiscal planning, project planning, creating specifications, procurement, politics, and leading public meetings. Both positions require an individual at the top with stellar organizational and planning skills and a positive demeanor supporting customers.

For a software company, every product requires support. Users will encounter defects, and those defects must quickly be researched, verified, and remediated. Customers will occasionally have ad-hoc, high-priority requests in response to their own business’ stimuli, colloquially referred to as “fires” by the production support team. In parallel, the support side of the firehouse handles responding to dispatched 911 calls and extinguishing actual, physical fire alerts sent through an Incident Command System. When asked which fires are harder to control, Ken quipped, “The actual fires … usually”. 

On both fronts, teams are composed of individuals with specific roles and skills. For a software company, those roles are typically developers, designers, quality assurance, and IT. Team members use their varied skills and come together to create solutions. When a challenge arises, Developers will research the code base and provide technical solutions. Production support accesses the logs in production and applies their working knowledge of the system and the user’s workflow to determine how to recreate the issue. IT investigates network, security, and server-related issues. The fire department is similarly multi-faceted. The engine company performs fire suppression, the truck company provides ventilation and search capabilities, and others whose job is to provide a water supply. Clearly, both organizations need a respected and capable leader to coordinate the varied problem resolution activities in a responsive and professional manner.

In the summer of 2021, Ken celebrated his 35th year with the Liberty Corner Fire Department. I’d like to extend the celebration by adding to it Ken’s 35th year of applying, like Liam Neeson (Taken), “a particular set of skills,” both technical and managerial, to every aspect of his professional and personal life.

1 http://www.libertycornerfire.org/ – please help their cause by donating!