Thursday 25 August 2022

3 challenges when introducing API-first to microservices - an interview with Alin Daniel Ferenczi

We have asked Alin Daniel Ferenczi about his experience with the API-first approach.  He is a Solution Architect and Deep Tech Investor with 7 years of experience working to disrupt traditional business workflows through automation or API integrations, microservice architecture and multi-cloud adoption for startups and large enterprises.

Traffic Parrot: Alin, in your experience, what is the difference in API-first approaches for monolithic and microservice architectures?

Alin: The main difference from an architecture standpoint consists in the distribution of responsibilities. Designing a system must focus on following the single responsibility principle. It is one of the simplest and most complex design principles and it can have a major impact on the entire approach. Splitting the responsibilities properly and following an API-first approach allows for teams to work in parallel increasing the speed to market.

Alin: In the monolith architecture, cross-cutting concerns such as logging, error handling, caching and performance monitoring affect only one application that encompasses the APIs. These services are usually more tightly coupled, and their responsibilities can become blurred at times. This implies an additional effort required to keep a close eye and avoid cluttering the code with logic that is redundant for the whole system.

Alin: Designing microservices requires a good segregation of responsibilities. This also implies that cross-cutting concerns need to be designed as individual services or integrated in each service individually which adds additional layers of complexity to each implementation.

Alin: Designing a good API-first architecture from the start is crucial for each system to ensure a good development cycle, faster delivery, scalability and reliability. Deciding on the responsibilities of each component requires a different paradigm between a monolith and microservices. 

Traffic Parrot: Alin, in your experience, what are the three main challenges for companies starting their API-first journey for microservice architectures?

Alin: There are quite a few issues that might arise from developing microservice architectures. My clients whether they have an existing monolith or are developing a brand-new API-first application based on microservice seem to struggle the most with synchronization between releases in order to properly test the integration of each API. Integration testing is a big part of a good release cycle and when the development time between services is quite large, it may cause unnecessary downtime for development teams. This happens especially if multiple frameworks are used for different APIs and the developers cannot contribute to the other projects.

Alin: API-first adoption additionally requires a shift in thinking to create better reusable APIs and the planning phase either is too hasty and the reusability is not as expected, or the plan takes too long to establish that other chances arise and need to be considered.

Alin: Another big issue that I have encountered is the lack of adoption of proper tools for documenting, style validation, mocking and versioning of the APIs. Onboarding new hires on existing projects requires proper documentation or sandbox environments so that the developers can try out the API endpoints to get familiar with the environment. A proper DevOps culture and a “set up once” mentality needs to be established together with processes for documentation, testing and releases in order to avoid repetitive tasks and focus the attention of the team towards more creative requirements.

Traffic Parrot: Alin, how do you currently solve those problems?

Alin:    We have managed to tackle the issue with synchronization between releases by sticking to a limited set of technologies whenever possible. Adopting alongside the API-first approach, an inner source initiative has also enabled people to collaborate better and help redistribute the free capacity of teams that had a faster pace.

Alin:    The inner source adoption has also helped the planning and managing of reusable components. Since everyone has access to every component, it is far easier to find overlaps between each API that is being developed and contribute to the reusable modules’ library.

 Alin:  Proper tooling might not be only a decision from the technology perspective. Financial aspects need to be taken into account and depending on the size of the organization it may take months before a tool can be adopted. Another alternative to acquiring tools can be improving the current workflow depending on the needs of each project. Since I am working both on architecture and on budget allocations / raising funds depending on the company, I am advocating for the adoption of new tools but if something can be achieved through better workflow management and better DevOps processes, I might decide to postpone or avoid additional costs.

Traffic Parrot: Alin, in your experience, what are the three main challenges for companies already using API-first?

Alin: From my experience the tasks from API-first architectures that require the most amount of effort/time and provide the least benefits are: understanding the differences between documentation and the actual implementation due to a lack of updates to the documentation or due to technical debt, mocking data for edge cases and requirements that change on a timely basis and failing to have a proper error handling system or contingency plans for APIs that are unhealthy.

Alin: The enormous amount of technical debt is an issue that every company struggles with or will do in the future, and it is the most likely cause for a company to refactor one or more APIs from their structure. This is a very good reason why the microservice architecture should be adopted whenever possible. Technical debt usually comes together with mismatches within documentation which can hurt the productivity of other people that will require to interact with the application.

Alin: Mocking data for edge cases and requirements can take days cumulatively for people to compose which even if done preventively it can still take time and additional costs to set up and if it is by any chance not as expected it can have an impact on the development cycle. Considering situations where data is time dependent this can become a major pain point for each release. Even with automated processes it may not cover all cases. If the data is tied to an external provider, it may not be as accurate as from the source directly.

Alin: API-first architectures that are structured as microservices imply that each component can have independent failures. This can be an advantage if properly structured to handle errors as it can quickly detect failures using health probes and take actions accordingly through disaster recovery plans without taking the entire system down. The issues and struggles that I have encountered of companies have been related to the design or misconfiguration of those plans either when checking the health system, taking actions, reporting / monitoring and mitigating business risks such as loss of data, breach of SLAs and so on.

Traffic Parrot: Alin, how do you currently address those challenges?

Alin:    Technical debt is hard to avoid. Refactoring is necessary from time to time and if it makes sense from a cost benefit analysis, I am suggesting pursuing such tedious tasks. There are a lot of examples of instances where refactoring of popular apps has helped them evolve and adapt to a larger user base. Especially when going from a proof of concept to large scale adoption of a new service, refactoring can be unavoidable. Knowing to focus on delivery and come with improvements later has helped me deliver faster and provider quicker adoption for applications.

Alin:    My favorite subject to talk about is automation and even when developing APIs and applications for automation, there are still cases where we can automate our own processes. Data generation and mocking is a great example of such a case. Pushing for prioritizing the automation of repetitive tasks has always been beneficial. If there are also companies such as TrafficParrot which can provide some of the automation beforehand and if the ROI of adopting external tools makes sense, it is even more beneficial so that internal developers can focus on more productive tasks.

Alin:    Testing disaster recovery plans regularly and improving them with each iteration is becoming more and more popular within multiple companies that I have interacted with. I am always trying to be up to date with the latest techniques for proper configurations and implementing them whenever capacity is available or when preparing for a disaster recovery exercise.

Next steps

Would you like to share your experience with the API-first approach? Please reach out to us and would be very much interested in hearing your thoughts and sharing them with our audience.

Would you like help with your API-first approach? A number of Traffic Parrot clients follow the API-first approach, and we would be happy to help you on your journey. 


Tuesday 2 August 2022

Traffic Parrot 5.34.0 released, what's new?

We have just released version 5.34.0. Here is a list of the changes that came with the release:

Features

Fixes

  • Library upgrades to fix OWASP issues