We’re at the verge of the age of massively distributed computing. Sure, we’ve been tiptoeing into distributed computing since we started with CORBA and Client Server. But today, things are accelerating. Seriously. Billions of mobile devices are connected to the internet and doing business. A growing proportion of cars and trucks is always connected. Things get connected. But, more importantly, organizations are getting smarter at interconnecting. Business integration is starting to take off. Deep collaboration across the value web opens up new ways of doing business together. From co-marketing to co-creation to co-production to co-service. Integrated care, perhaps. Or joint operations. And interconnected systems are the main driver of change. But how should you design your IT to fully enable this. How can you empower smarter ways of working? How can you reap the benefits of massively distributed computing? Well, here’s how.
API First Design
Who doesn’t love APIs? Conceptually, they’re very simple. Thanks to the Open API Specification, widely embraced in the industry, it has become super easy to define and document application interfaces concisely, consistently and clearly. And there is great tooling to publish, discover and test APIs. That gets the first prerequisite for successful implementation of massively distributed systems covered. And there is additional tooling to securely manage access to APIs – yet another prerequisite WSO2 API Manager covers nicely.
Now that’s a great starter, but where does it get us? Think along. If a developer starts his understanding of distributed systems at the API level, as he should, should API design not equally be the starting point for the architect? Of course, it should! There is no better way to start designing a distributed system than through its interfaces. When you think your interfaces through, you will think about all the components, and how they exchange information. What input do they expect, and what output will they generate? What are the error conditions you expect? Implicitly, you demarcate responsibilities, and identify your resources. That’s architecture at work.
In many cases, you’ll already have data sources and services available to start from. Given the right technology, you can bring your APIs to life from their earliest stages of design. That’s powerful. Alternatively, you can prototype your APIs with a simple inline script. Let the early testing commence.
Security First Design
But wait, there’s more. In today’s world, you have to design with security in mind. Your services might be able to exchange information freely, but this is not always what’s needed. Information may be sensitive, or restricted to particular usage. There can be privacy restrictions at play. Or intellectual property. Trade secrets, perhaps.
Once again, APIs are your friend. It’s a good practice to restrict access to APIs to targeted developers. In security thinking, access is forbidden unless explicitly granted. So, whom do you grant access to your API? There is no better time to pinpoint your target audience then right when you define your API. One step further, you must think about access at the method level. Perhaps certain methods are restricted to certain developers. Or maybe, you have to restrict access to certain groups of runtime users. Anyway, it is a good practice to always define a scope for a method. Once again, even if the scope is ‘everybody’, it must be an explicit decision. For a deeper dive into API security, please check our blog on inherently secure APIs [insert ref].
At times, authorization logic is more fine-grained. That’s when access to a method is conditional. There may be multiple types of conditions you have to enforce here. For instance: You are allowed to do a transaction, provided you have been strongly authenticated. Or provided you’re accessing from a certain geography. These are cases of adaptive authentication at play. Alternatively, there may be some business logic involved. You’re allowed to order alcoholic beverages, but only if you’re over 18 years old. You’re allowed to access a medical file, but only if it’s of your patient. Fortunately, WSO2 API Manager allows you to enforce smart policies like these right at the interface level.
A strong design comes with strong security, and APIs help make that happen.
From theory into practice
By now, you should be not only convinced, but also super motivated to start your API first design. But then you’ll also need the technology to play with. Since you’re most likely not designing in an ivory tower, you’ll want to collaborate with people inside and outside your team. Which requires yet more technology. And if you’re lucky enough to have access to suitable technology yourself, chances are this is not the case for everyone in your extended team.
It is one of the many great benefits of Yenlo Connext to bring rich integration and collaboration technology to everyone who is involved. We understand technology should be an enabler, not a constraint. With Connext, you have the platform to start designing your APIs, including their policies, and start testing them from day one, thanks to the great WSO2 API Manager. Identity and Entitlement management is fully covered in WSO2 Identity Server. You can bring your APIs to life with a few clicks in the WSO2 Developer Studio and help of the WSO2 ESB. And there’s so much more to choose from. We’ve even included a wiki and a project tracking solution to support an agile way of working.
Did you know you can generate SDKs for your APIs with a press on the button? Yenlo Connext supports a host of target languages and frameworks, such as Android, Angular, Go,Python, Perl, and Swift. You can even generate a server stub in ASP.Net, Java, Spring, NodeJS and Ruby, amongst others.
That’s how we can boost your integration efforts. However massively you distribute your systems. At whatever scale you want to operate. Try us. Contact us for more information.