As technology evolves, it tends to recycle some concepts that are empowered by how they improve and find new ways of solving recurrent problems, making our lives easier. Exposing functionality through services is not a new concept, it has been cooking for a while, since RPC calls to SOA. It has been evolving to simplify how we can connect systems, regardless of the technology they are built in.
More recently, we are connecting companies through APIs, offering not only specific information as traditional integration would do, but moreover, providing full services such as: creating a banking account, see maps real time, integrating social network services and so on and so forth.
Here is a quick list of what in my experience you should and shouldn’t do if you want to go down the road of exposing services, either internally or outside your organisation.
Build an Architecture
Design and build an architecture where your services will be living, regardless of if you are going for an API led connectivity, API gateways or just microservices, will surely save you some headaches in the future.
At first, architectures might seem like they take quite some time, but it is time well spent. A properly defined architecture will help you put things where they belong and more importantly, everyone working with the architecture will know where to put them, instead of just developing as you go basis.
Make it scalable – Be sure to design an architecture that will cope with growth and the load expected by the business.
“There is nothing more satisfying than seeing code in a well-structured way, following patterns and best practices. It reduces the teams’ learning curve and helps the debugging process, since understanding the code/ implementation is less challenging when using a well-defined standard”
It must perform – Its great if your design escalates, but it takes a lot out of it if it is slow, it must be quick and keep it that way when it grows. Designs commonly fail due to lagging response times and addressing that when its live might be a nightmare, so anticipating and designing to perform plays an important part of your architecture. Non-functional testing (performance, load, concurrence, usability, reliability, etc.) should help you make sure where you solution stands in terms of performance.
Don’t Over Design
Simple designs are effectively more efficient and age better than overengineered designs, that make it so complex to implement that teams will struggle when building over it, probably leading them to work around it. Be sure that you test your design, all ideas no matter how good they are, need to be tested. Make sure you do.
Define Standards
There is nothing more satisfying that seeing code in a well-structured way, following patterns and best practices. It reduces the teams learning curve and helps the debugging process, since understanding the code/implementation is less challenging when using a well-defined standard
These standards must work for both the architecture and development team, whey can agree and meet halfway through these standards easing the way both teams interact.
Don’t neglect Security
While implementing new functionality in our shiny new architecture might be exciting, security its paramount for it to be well round up. Use automated tools that will help you scan your code for vulnerability, security breaches and code quality. SonarQube is a popular, easy to implement tool that will get you going. An occasional pen test carried out by a third party will keep your mind at ease, you can also use Burp suite to perform security testing. Remember to have a security expert next to you to guide you through the process. Security is not limited to code; authentication (tokens, OAuth2, JWT), authorisation (2FA, OTP, OTC) and code vulnerabilities play a big part of it, alongside many more things.
Define Standards
There is nothing more satisfying that seeing code in a well-structured way, following patterns and best practices. It reduces the teams learning curve and helps the debugging process, since understanding the code/implementation becomes less challenging when using a well-defined standard
These standards must work for both the architecture and development team, where them both can agree and meet halfway through these standards easing the way both teams interact.
Don’t work in silos
Working in silos might break your architecture, generating duplicated services, operations, or entire functionality. A proper service governance might help you reuse and avoid unwanted extra effort, while it would also save you from wasting resources (human, physical and technological)
Do consider as well governance and supervision on your standards and architecture, make sure that teams feel the need to comply with everything that is defined so they become advocates of how things should work, this approach will broaden the control to all team members instead of centralising in just in one governance team, that in fact will be checking that everything complies.
Create a Service Economy
Service economy relates to exchange value between organisations, it enables your organisation to use services from other providers, to offer more services without the need of building them yourself, there are popular services used by multiple applications such as twitter services to authenticate, Google APIs that embed maps into applications, more sophisticated services that can create bank accounts or wire transfers, this is leading to embedded finance, which is offering banking products in nonbanking apps.
A service architecture can be carried out with a number of technologies, microservices and APIs are becoming very popular lately due to its simplicity to integrate, develop, loosely couple, independent and how it horizontally escalates, being a cloud native concept, will also save you time when provisioning infrastructure while it enhances your apps, website, or platforms business capabilities.
