How Microservices Comes Together Brilliantly with DevOps?

Do you know what’s common to Amazon, Netflix, and NASA?

All three of them use DevOps.

Amazon uses it to deploy new software to production at an average of every 11.6 seconds!

Netflix uses it to deploy web images into its web-based platform. They have even automated monitoring wherein they ensure that in the event of a failure in implementing the images, the new images are rolled back, and the traffic is rerouted to the old version.

NASA, on the other hand, used it to analyze data collected from the Mars Rover Curiosity.

It’s become such that every organization that focuses on quick deployments of software and faster go-to-market uses DevOps.

How microservices comes together brilliantly with DevOps?

Statista reveals that 17% of enterprises had fully embraced DevOps in 2018 as compared to 10% in 2017.

Given the advantages, these numbers will only grow every year as companies transition from the waterfall approaches to develop fast, fail quickly, and move ahead on the principles of the agile approach.

But for DevOps to deliver to its fullest potential, companies need to move from the monolithic architecture of application development to microservices architecture.

What is Microservices Architecture?

Unlike monolithic architecture, where the entire application is developed as a single unit, Microservices structures applications as a collection of services.It enables the team to build and deliver large, complex applications within a short duration.

How can Microservices Work with DevOps?

Microservices architecture enables organizations to adopt a decentralized approach to building software. This allows the developers to break the software development process into small, independent pieces that can be managed easily. These developed pieces can communicate with each other and work seamlessly. The best part about microservices architecture is it allows you to trace bugs easily and debug them without leading to redeveloping the entire software. This is also great from the customer experience perspective as they can still use the software without any significant downtime or disruption. It’s a perfect fit for organizations that use DevOps to deploy software products.

No wonder organizations like Netflix, Amazon, and Twitter that were using a monolithic architecture have transitioned towards a microservices architecture.

Let’s look at the benefits of Combining DevOps with Microservice Architecture:-

  • Continuous Deployment: Remember the Netflix example we gave at the beginning about how Netflix reroutes the traffic to the old version of web images if they are not deployed on time? Imagine if Netflix still used monolithic architecture or the waterfall method of software deployment, do you think they would have been able to give the same kind of customer experience you witness today? Most likely, not! Microservices architecture coupled with DevOps enables continuous delivery and deployment of software, which means more software releases and better quality codes.
  • More innovations and More Motivation: Imagine working on a product for 2-3 years and then knowing it is not acceptable to the market!It becomes hard to pivot too. Often you realize that there are several bugs, the process has become unnecessarily lengthy, and you have no clue which team is working on what. Wouldn’t it lower your morale? However, those days have gone. Today, organizations have transitioned from a project to a product approach. There are smaller decentralized teams of 5-7 people that have their own set of KPIs and success metrics to achieve. This allows them to take ownership of “their” product and it gives them better clarity on the progress. It also gives them the freedom to innovate, which boosts their morale.
  • High-quality Products: With the power of continuous deployment and the freedom to experiment and innovate, organizations can continuously make incremental changes to the code leading to better quality products. It allows teams to mitigate risks by plugging the security loopholes, make changes to the product based on customer feedback, and reduce downtimes.

As you can see, using DevOps and microservices architecture together will not only boost the productivity of the team, but it will also enable them to develop a more innovative and better quality product at a faster pace. It helps product teams develop products in a granular manner rather than taking a “do it all at once” approach.

However, to embrace DevOps and microservices, you have to ensure that your teams understand the core benefits and make the most of the change.

Teams usually work in silos – the development team works independently, the testing team does its job, and so on. There is an obvious gap in communication, which leads to a delay in completing development and testing. DevOps and microservices require teams to work in tight collaboration. You will have to foster an environment where there are cross-functional teams of testers and developers communicating and working together to complete a task. This will help the teams to accelerate the process of developing, testing, and deploying their piece of work at a faster pace.

Of course, it is not easy to introduce a culture of collaboration, given that people are accustomed to working in silos. Hence, it is essential to reduce friction before starting the initiative. Once everyone shares in the vision and understands their own role in getting there, developing products with DevOps while leveraging a microservices architecture will become much easier.

Key Considerations While Shifting to Microservices Architecture

 

What Exactly is a Microservice?

Microservices is a method of structuring a software or an application as a loosely coupled service. Each service executes one function and is a component of the system that can be developed, maintained, and scaled individually. Each module supports one goal and uses a simple interface to communicate with other services.

Traditionally, software programs were built using a monolithic approach, where the entire software was built as a single unit. For eg., the entire unit would be responsible for database operations, executing business logic, handling HTTPS requests, background processing, client communication, user authentication, and so on.

Key considerations while shifting to a microservices architecture

In this structure, every tiny change in the system would require rebuilding, checking, and deploying the entire application. Change, even in a line of code, would prompt developers to make a new build of the complete system, which was time-consuming.

It became clear that the monolithic architecture was holding back innovation, scalability, agility, and independence. The microservices approach brings all this and more. Where there is a large system with intricate component management, scaling, and individual development, microservices has become the obvious choice.

However, making that move from monolithic to microservices isn’t easy. There are several considerations to factors in.

Key Considerations for Businesses Shifiting To Microservices Architecture :

  • Degree of Independence – The first thing to consider is the level of independence you want for the services in your microservices architecture. In the first approach, each service is completely independent with its own UI and database. This would be an instance of an extreme microservices architecture where services are entirely decoupled and share nothing. The difficulty arises in ensuring all datastores stay in sync and updated at all times. To rectify this, in the second approach, you can choose to share some components between the services, such as the database. This would make it easier for you to ensure data consistency and enforce data standards, regulations, and compliances within the software.
  • Technology Stack – It’s hard enough to decide a tech stack for a monolithic application. Now, imagine doing that for each service within a microservices architecture. If your services are heterogeneous, this could create an issue with standardization. Moreover, it becomes harder for your people to move between teams if every team uses a different tech stack. A recommended approach is to take a balanced approach in deciding the desirable tech stack across the application. If a team wants to override the default choice, they will have to support their decision with the pros and cons of the change that compelled their decision. The ideal tech stack may include the cloud provider, infrastructure, storage, monitoring, programming language, and a testing and logging framework.
  • Complexity – Microservices impacts the operational complexity of the underlying application. You need to consider aspects such as the infrastructure which needs to be scaled up and down for a sophisticated level of automation. Load balancing and scaling, which will happen either for all services or only a few, will be a concern. Service discovery as services in a microservices world changes dynamically due to upgrades and scaling and that should be part of the consideration set. As should be monitoring, which needs to be configured for each service individually. And, think of the capability to handle scenarios when a subset of services are scaled up or down.
  • Decouple Capabilities – There is a definite cost associated with moving to microservices from monolithic systems. Therefore, you’d want to consider what capability your systems have that can be decoupled and how you can migrate incrementally. Assess this in your system by taking a look at the operational readiness for creating services or migrating them. The primary idea is to start with capabilities that are fairly decoupled right in the monolith. These could be services that don’t require changes to several client-facing applications that use monolith and don’t use a data store. After decoupling simple edge services, consider those deeply embedded in the monolithic architecture.
  • Continuous Delivery – As Martin Fowler points out in his article on microservices tradeoffs, easily deploying small independent units is a blessing for development, but operations get more complicated as a few applications become hundreds of microservices. This reinforces the vital role of continuous delivery. While CD is a valuable skill for monoliths, it’s absolutely essential for microservices. Organizations such as Netflix and Amazon have spent their energy in building homegrown custom continuous delivery pipelines for microservices. As an alternative, organizations can choose a CD automation platform for a less intensive choice.
  • Data Services – Refactoring the underlying data structures is one of the most complex issues of migrating to microservices. There are several models that you can follow. Use reference data to populate drop-downs in GUIs, Master Data Management to eliminate several views of an entity such as the customer within a database, flat object structure to store documents such as feedback surveys, independent tables to support data retrieval with SQL, and blob storage for storing a structured Java object, for instance.
  • Team Organization – Lastly, you must reorganize your teams to ensure that all services are developed, deployed, and maintained independently. You may need an independent team to work on each microservice because when engineers work on multiple microservices, they might make optimization decisions that are not in the best interest of all associated services. Each team may need to have capabilities such as development, testing, Ops, database administration, UX, and product management. The central idea is to organize teams for maximum optimization of each microservice, without dependence on other teams.

Challenges of Shifting to Microservices and Why you need a Reliable Partner:

As you would have inferred, migrating from a monolithic architecture to microservices isn’t a job for everyone. When you need to make so many key considerations and weigh several pros and cons, you need specialized assistance from a reliable partner.

At ThinkSys, we make microservices possible even when you have a hyper-complex monolithic application architecture. We can ease the many hiccups you might encounter in that shift. 

Talk to Our Team Today

Application Development with Microservices in the DevOps Age

Does anyone even remember when companies developed an entire product, tested it, fixed it, and then shipped it? The entire process would take months, even years, before a functioning product made it to the customer. Before the product hit the market, neither did the potential customers know what it held for them and neither did the product owners know if it would hit or miss the mark.

Today, product users expect to be a part of the development process. They want to contribute their insights to develop a product that matches their ongoing needs. The need is for continuous innovation and improvements. The need is for DevOps!

DevOps combines technology and cultural philosophies to deliver products and services quickly. It is a continuous process of developing, testing, deploying, failing, and fixing applications to achieve market-fit. Jez Humble, one of the leading voices of DevOps sums it up “DevOps is not a goal, but a never-ending process of continual improvement.”

microservices Application development in Devops age

Today, DevOps is not just for a handful of large enterprises. According to Statista, the number of companies adopting DevOps went up by 17% in 2018

A quick look at what has made DevOps popular?

Apart from the continuous innovations and improvements, DevOps also helps in:

  • Improving customer satisfaction: With a DevOps mindset, companies use advanced methods to identify issues and fix them real-time before the customer is impacted. There is also scope to improve the product on-the-go driven by frequent suggestions and feedback from customers. Continuous improvement in quality leads to customer delight. Take Rabobank of Netherlands, for example. This large financial institution has over 60,000 employees and hundreds of customer-facing applications. As the deployments were manual, the failure rate was over 20%, and they received many complaints about delays. When they moved to DevOps, they were able to deploy applications 30x more frequently with a lead time that was 8,000 times faster than their peers.
  • Change in organizational culture: DevOps has played a significant role in breaking silos and boosting the collaborative culture in companies. In an agile environment, working in silos can slow down the process of developing, testing, and releasing the product. A DevOps team will be able to collaborate better and ramp up the process of developing, testing, and troubleshooting the product. 
  • A decrease in failure rates: According to the State of DevOps report, high-performing DevOps organizations have seen a reduction of failure rates of 3x, thanks to their ability to find and fix errors early in the cycle.
  • Higher productivity: DevOps organizations can deploy products 200x more frequently than a non-DevOps organization, leading to happier and highly motivated teams. Take Microsoft’s Bing, for example. It has moved developers to a DevOps environment with the idea of continuous delivery and innovation deeply ingrained within their processes. The result? Bing deploys thousands of services 20 times a week and pushes out 4000 individual changes every week. The continuous effort by the team to deliver has made Bing the second largest search engine in the world.

While adopting a DevOps culture is essential for a company to thrive, it is also crucial that they have the right architecture and systems in place to complement their principle of continuous delivery and innovation. That’s where microservices is now playing a massive role.

Micro-services and Their Role in DevOps Organization:

For a long time, companies relied on a monolithic architecture to build their application. As monolithic applications are built as a single unit, even a small change in a single element made it necessary to build a completely new version of the application. 

With more and more companies moving towards DevOps, such a monolithic architecture makes it difficult to implement changes rapidly. The need for greater agility gave rise to a new type of architecture -enter microservices. 

With Microservices, an application is built on small, independent components that are independently deployable. Although independent, these components communicate with each other via RESTful APIs. So, even if a single piece of code has to be changed in a single element, the developer does not have to build a new version of the whole product. They can simply make the changes to the individual components without affecting the entire application, making the deployment efficient and faster. 

For companies that have adopted the DevOps culture, developing applications with microservices has several benefits that include:

  • Easy rectification of errors: When a component fails the test or requires changes, it is easy to isolate and fix. This makes it easier for companies to fix errors quickly without affecting the users of other services.
  • Better collaboration: Unlike a monolithic architecture where the different teams focus only on specific functions such as UX, UI, server, etc, a microservices architecture encourages a cross-functional way of working. 
  • Decentralized governance: Monolithic architecture uses a centralized database, while microservices use a decentralized method of governance, wherein each service manages its database. This makes it easier for developers to produce tools that also can be used by others to solve specific issues.

A key trend accelerating the adoption of Microservices in such scenarios is Containerization. Containerization allows code for specific elements to be carved out, packaged with all the relevant dependencies, and then run on any infrastructure. These applications can be deployed faster and can be made secure. The applications are extremely portable and adaptable to run on different environments. 

Companies like Amazon and Netflix have shifted to microservices to scale their business and improve customer satisfaction. 

Product companies aiming to become customer-centric and delight with continuous improvement in the product may find it essential to adopt a DevOps mindset married to a transition to the microservices architecture

Of course, it will take some time to transition product development. Teething problems are bound to arise, including duplication of efforts due to the distributed deployment system. However, given the larger picture and the potential benefits, it’s a wise move for product companies to make. 

Test Automation for Microservices- Here’s What You Need to Know

We have written a couple of times in the past about Microservices. The approaches are evolving, and this blog is an attempt to address a specific question -while testing microservices, does test automation have a role?

Just a little refresher first. As the name suggests, microservices are nothing but a combination of multiple small services that make up a whole. It is a unique method of developing software systems that focus on creating single-function modules with well-defined interfaces and operations. An application built as microservices can be broken down into multiple component services. Each of these services can be deployed, modified, and then redeployed individually without compromising the integrity of an application. This enables you to change one or more distinct services (as and when required) instead of having to redeploy the application as a whole.

Microservices are also highly intelligent. They receive requests, process them, and produce a response accordingly. They have smart points that process information and apply logic, and then direct the flow of the information.

automation testing microservices

Microservices architecture is ideal in the case of evolutionary systems, for eg. where it is not possible to thoroughly anticipate the types of devices that may be accessing the application in the future. Many software products start based on a monolithic architecture but can be gradually revamped to microservices as and when unforeseen requirements surface that interact over an older unified architecture through APIs.

Why is Testing for Microservices Complicated?

In the traditional approach to testing, every bit of code needs to be tested individually using unit tests. As parts are consolidated together, they should be tested with integration testing. Once all these tests pass, a release candidate is created. This, in turn, is put through system testing, regression testing, and user-acceptance testing. If all is well, QA will sign-off, and the release will roll out. This might be accelerated while developing in Agile, but the underlying principle would hold.

This approach does not work for testing microservices. This is mainly because apps built on microservices use multiple services. All these services may not be available on staging at the same time or in the same form as they are during production. Secondly, microservices scale up and share the demand. Therefore, testing microservices using traditional approaches can be difficult. In that scenario, an effective way to conduct microservices testing is to leverage test automation.

Quick Tips on How to Automate Testing for Microservices:

Here are some quick tips that will help you while testing your microservices-based application using test automation.

  • Manage each service as a software module.
  • List the essential links in your architecture and test them
  • Do not attempt to gather the entire microservices environment in a small test setup.
  • Test across different setups.

How to Conduct Test Automation for Microservices?

  1. Each Service Should Be Tested Individually: Test automation can be a powerful mechanism for testing microservices. It is relatively easy to create a simple test script that regularly calls the service and matches a known set of inputs against a proposed output. This function by itself will free up your testing team’s time and allow them to concentrate on testing that is more complex.
  2. Test the Different Functionalities of your Microservices-based Application: Once the vital functional elements of the microservices-based application have been identified, they should be tested much like you would conduct integration testing in the traditional approach. In this case, the benefits of test automation are obvious. You can quickly generate test scripts that are run each time one of the microservices is updated. By analyzing and comparing the outputs of the new code with the previous one, you can establish if anything has changed or has broken.
  3. Refrain from Testing in a Small Setup: Instead of conducted testing in small local environments, consider leveraging cloud-based testing. This allows you to dynamically allocate resources as your tests need them and freeing them up when your tests have completed.
  4. Test Across Diverse Setups: While testing microservices, use multiple environments to test your code. The reason behind this is to expose your code to even slight variations in parameters like underlying hardware, library versions, etc. that might affect it when you deploy to production.

Microservices architecture is a powerful idea that offers several benefits for designing and implementing enterprise applications. This is why it is being adopted by several leading software development organizations. A few examples of inspirational software teams leveraging microservices include Netflix, Amazon, eBay, etc. If like these software teams, your product development is also adopting microservices then testing would undoubtedly be in focus. As we have seen, testing these applications is a complex task and traditional methods will not do the job. To thoroughly test an application built on this model, it may be essential to adopt test automation. Would you agree?

moceroservices testing

How the Microservices Landscape Has Changed In The Last Year & a Bit?

2016 proved to be the year of Cloud, DevOps, and Microservices. While organizations across the globe realized that Microservices was a great way to leverage the potential of the cloud, it was made evident that DevOps and Microservices worked better together to provide business agility and increase efficiencies. It became evidently clear that traditional, large and monolithic application models and architectures did not have any place in the organization of the future. Technologies such as the cloud demanded application architectures that enabled greater scalability with workload changes and greater flexibility to accommodate the evolving needs of the digital enterprise. 2016 proved that monolithic application architectures running on the cloud did not deliver the promised benefits of the cloud and that a Microservices architecture was best suited to leverage the benefit of this technology.

  1. The Bump on the Road
    In one of our blogs published last year, we had spoken of Microservices and the testing needs of applications built using the microservices architecture. One of the greatest challenges of microservices testing is testing each and every component individually as well as a part of an interconnected system. Each component or service is expected to be a part of an interconnected structure and yet is independent of it. However, as Microservices adoption increased, a number of organizations also realized that despite the promise, latency issues when accessing these applications continued. Along with this, Microservices brokered by API management tools further escalated the latency problem since that introduced an additional layer between the user and the microservice. Also, Microservices used up a large amount of virtual machine resources when they were deployed on virtual machines.
  2. Microservices and Containers – A Match Made In Heaven
    In 2016, the value of using Microservices and the Cloud became evident. 2017 promises to show the value of Microservices with Containers to break the barriers that impede cloud usage. One of the key problems plaguing Microservices in 2017 is that of resource efficiency and Containers can be used to solve this problem. Organizations are leaning in to use Containers with Microservices. Containers increase the performance of these applications and aid portability and also decrease hardware overhead costs.Containers, unlike virtual machines, allows the break down of the application into modular parts. This allows different development teams to work on different parts of the application simultaneously without impacting the other parts. This aids the speed of development, testing, application upgrades and deployment. Since there is a reduced duplication of large software elements, multiple microservices can easily run on a single server. As compared to VMs, Microservices would deploy faster on Containers. This helps during horizontal scaling of applications or services with load or if a microservice has to be redeployed.Along with increasing resource and deployment efficiency, Container adoption in Microservices has been increasing owing to the level of application optimization Containers offer. Container clouds also are networked on a much larger scale and allow the service discovery pattern to locate new services in the microservices architecture. While this level of optimization can be achieved by VM’s, it becomes more complex since these demand explicit management policies.
  3. Rise of Microservices In DevOps:
    The past year also saw an increased use of Microservices in DevOps. Since Microservices offers the benefits of scalability, modifiability, and management owing to its independent structure, it fits in comfortably with the DevOps concept. Microservices offer the benefit of increased agility owing to shorter build, test and deployment cycles, making it perfect to complement a DevOps environment. With the increasing adoption of Containers in Microservices, organizations are now able to use the DevOps environment better to deliver new services by streamlining the DevOps workflow. Fault isolation also becomes inherently easier by using Microservices in DevOps. Each service can be deployed independently and identifying a problematic component becomes easier.
  4. Automation Focus Increases:
    Organizations leveraging Microservices and DevOps are also increasing the levels of automation in the testing initiatives. Owing to the DevOps methodology, test automation has found a firm footing in the microservices landscape with testing in production, proactive monitoring and alerts becoming a part of the overall quality plan.A year is a long time in the field of software development. When it comes to Microservices we are seeing organizations leveraging development methodologies like DevOps and technologies such as Containers in a symbiotic manner to propel growth, increases efficiencies and improve business outcomes for all. How has your Microservices journey been?
Distributed-Engineering-Teams

Ensuring High Productivity Even With Distributed Engineering Teams

The traditional workspace has been witnessing an overhaul. From traditional cubicles to the open office concept to the standing workspace… new trends to increase employee productivity arise every day. One such concept, a fundamentally different way of working when it arrived, has now cemented its place in the industry – that of the distributed teams. Successful implementation of a distributed workforce by companies such as Mozilla, GitHub, MySQL, Buffer, WordPress, and more are a testament to the fact that geographical boundaries cannot deter employee productivity and accountability. In fact, WordPress has over 200 employees distributed all across the globe and contributing successfully in their individual job roles.

Having a distributed workforce has definite advantages. It brings more diversity in business, provides new perspectives to problem-solving, opens up a wider pool of trained resources, and reduces operational costs. Further, a study conducted by BCG and WHU-Otto Beisheim School of Management showed that well managed distributed teams can outperform those who share an office space. However, ensuring high productivity of a distributed engineering team demands ninja-like management precision.

In our experience of years working in a distributed setup with our clients, we realized that one of the greatest benefits of having such a workforce was the immense intellectual capital we had harnessed. We now have some truly bright engineers working for us. Our client’s teams located in the United States and our team in India successfully collaborate on software projects without a hitch. Let’s take a look at how we make these distributed engineering teams work productively, focus on rapid application delivery and produce high-quality software each time.

Have a Well Defined Ecosystem

First, it is imperative to have a well-defined ecosystem for a distributed team to work and deliver high-quality applications in a cost-effective manner. You need to have the right processes, knowledge experts, accelerators, continuous evaluation of tools and technologies in use, strong testing practices, etc. Along with this, it’s key to establish clear communication processes and optimal documentation. Leverage business communication tools and dashboards for predictability, transparency, to avoid timeline overruns. Further, it is essential to have all the important project stakeholders such as the product owner, the team lead, the architecture owner etc. together at the beginning of each project to outline the scope and technical strategy for a uniform vision.

Have Designated Project Managers In Each Location

Distributed teams demand a hybrid approach to project management. It helps, but may not be essential, to have the stakeholders shouldering lead roles such as the architects and the project managers to be in the same location or the same time zone as the client. Along with this, it is also essential to have a lead who will serve as the single point of contact and will be the local team’s spokesperson to streamline communication, help the team stay on track and avoid delivery delays.

Appropriate Work Allocation and Accountability
Appropriate work allocation is an essential ingredient that can make or break distributed engineering teams. Instead of assigning work based on location, it should be assigned based on team capacity, skills, and the release and sprint goals. Having cross-functional teams that can work independently with inputs from the product owner help considerably in increasing team productivity so that work can be redistributed in the case of sprint backlogs. Giving each team member ownership of a feature can also increase accountability, measurability and ultimately the productivity of the entire team.

Have a Common Engineering and Development Language
At the onset of the project, it is essential to establish the engineering and development language for project success. Having clearly outlined development procedures, code styles, standards, and patterns contributes to building a strong product irrespective of the teams’ locational distribution as the code merges and integrations are likely to have much fewer defects. It is also important to have aligned and standardized tools to avoid spending time understanding or troubleshooting tool configurations or properties. Having a team buy-in regarding the engineering methodology (are you going to use TDD, BDD or traditional agile etc.?) helps in eliminating subjectivity and ambiguity regarding the same. It is essential to also have clearly outlined coding standards, technologies of choice, tools, and architectural design to avoid misalignment of values and engineering standards.

Such relevant information should also be published and maintained in the shared community (a virtual community across the distributed teams that serves as a single information source) using tools and dashboards that provide comprehensive information at a glance even for the uninitiated.

Leverage Time Zones Optimally

In order to ensure the same level of communication in a distributed team as found in a co-located team, there has to be impeccable time zone management by establishing some overlapping work hours. By doing so it becomes easier to involve the key stakeholders in sprint planning, sprint review, daily stand-ups, retrospectives etc. In the case of a distributed team, it makes sense to break down sprint planning into two parts – one, which determines what each team is doing on a high level and develops the understanding of Sprint backlogs and dependencies. And two, for detail clarification and breaking down of stories into ‘tasks’. It is also important to have a remote proxy for Sprint review to establish what each local team has completed.

Testing is another important aspect that can impact the productivity of distributed engineering teams. Since most distributed teams leverage ‘Follow the Sun’ principle, activities such as testing can be passed on to the other time zone. So, by the time the development team is back to work, the testing work is already done. This can significantly improve the productivity of the engineering team.

Have An Integrated Code Base

When working towards ensuring the productivity of distributed engineering teams it is imperative to have a single code repository to ensure that everyone checks the same code base. Ensuring that all teams have access to the same CI server to ensure that all builds and tests are run against any iterations prevents build breakages and the eventual productivity loss. Along with this, it is also essential to have a hot back-up server in each location to battle adversities such as server downtimes, power outages etc.

Along with all this, there is another critical ingredient that helps in making distributed engineering teams more productive…trust. It is essential for the distributed teams to trust one another and function as a single cohesive unit. Understanding cultural differences, respecting time zones, and having clear communication between team members are few things can build trust within team members, foster collaboration and contribute towards creating a highly productive distributed engineering team. That’s ours- what’s your story about distributed engineering teams?

Software testing for Microservices Architecture

Over the last few years, Microservices has silently but surely made its presence felt in the crowded software architecture market. The Microservices architecture deviates from the traditional monolithic application built where the application is built as a single unit. While the monolithic architecture is quite sound, frustrations around it are building especially since more and more applications are being deployed in the Cloud. Microservices architecture has a modular structure where instead of plugging together components, the software is componentized by breaking it down into services. The applications, hence, are built like a suite of services that are independently deployable, scalable and even provide the flexibility for different services to be written in different languages. Further this approach also helps enables parallel development across multiple teams.
testing microservices architecture
Quite obviously, the testing strategy that applied to monolithic needs to change with the shift to micro services. Considering that applications built in the micro services architecture deliver highly on functionality and performance, testing has to cover each layer and between the layers of the service and at the same time remain lightweight. However, because of the distributed nature of micro services development, testing can often be a big challenge. Some of the challenges faced are as follows:

  • An inclination of testing teams to use Web API testing tools built around SOA testing which can prove to be a problem. Since the services are developed by different teams, timely availability of all services for testing can be a challenge.
  • Identifying the right amount of testing at each point in the test life cycle
  • Complicated extraction logs during testing and data verification
  • Considering that development is agile and not integrated, availability of a dedicated test environment can be a challenge.

Mike Cohn’s Testing Pyramid can help greatly in drawing the test strategy to identify how much of testing is required. According to this pyramid, taking a bottom-up approach to testing and factoring in the automation effort required at each stage can help address the challenges mentioned above.

  1. Unit Testing
    The scope of unit testing is internal to the service and is written around a group of related cases. Since the number of unit tests is higher in number they should ideally be automated. Unit testing in micro services has to amalgamate Sociable unit testing and Solitary unit testing to check the behaviors of the modules by observing changes in their state and also look at the interactions between the object and its dependencies. However, testers need to ensure that while unit tests constrain the ‘behavior’ of the unit under test, the tests do not constrain the ‘implementation’. They can do so by constantly questioning the value of the unit test in comparison with the maintenance cost or the cost of implementation constraint.
  2. Integration Testing
    While testing the modules in isolation is essential, it is equally important to test that each module interacts correctly with its collaborator and test them as a subsystem to identify interface defects. This can be done with the help of integration tests. The aim of the integration test is to check how the modules interact with external components by checking the success and error paths through the integration module. Conducting ‘gateway integration tests’ and ‘persistence integration tests’ provide the assurances help in providing fast feedback by identifying logic regression and breakages between external components which ultimately helps in assessing the correctness of logic contained in each individual module.
  3. Component testing
    Component testing in microservices demands that each component is tested in isolation by replacing external collaborators using test doubles and internal API endpoints. This provides the tester a controlled testing environment and helps them drive the tests from the customers perspective, allows comprehensive testing, improves test execution times and reduces build complexity by minimizing moving parts. Component tests also identify if the microservice has the correct network configuration and its capability to handle network requests.
  4. Contract Testing
    The above three tests provide a high test coverage of the modules. However, they do not check if the external dependencies support end-to-end business flow. Contract testing tests the boundaries of the external services to check the input and output of the service calls and test if the service meets its contract expectation. Aggregating the results of all the consumer contract tests helps the maintainers make changes to a service, if required, without impacting the consumer and also help considerably when new services are being defined.
  5. End-to- End Testing
    Along with testing the services, testers also need to ensure that the application meets the business goals irrespective of the architecture used to build it and test how the completely integrated system operates. End-to-end testing thus forms an important part of the testing strategy in micro services. Apart from this, considering that there are several moving parts for the same behavior in micro services architecture, end-to-end tests identify coverage gaps and ensure that business functions do not get impacted during architectural refactoring.

Conclusion
Testing in micro services has to be more granular and yet, at the same time, avoid become brittle and time-consuming. For a strong test strategy, testers need to define the services properly and have well-defined boundaries. Given that the software industry is leaning in greatly towards micro services, testers of these applications might need to change processes and implement tests directly at the service level. By doing so, not only will they be able to test each component properly, they will also have more time to focus on the end-to-end testing process when the application is integrated and deliver a superior product.

Categories
Follow us on Twitter