How to powerfully shape Developer Experience for Azure Logic Apps and AWS AppFlow

Establishing which online services your company provides are of interest to other companies through a business perspective alone is not easy. How do you establish your price, the suitable SLA or the complexity of the configuration options you make available? Equally relevant is the consideration of exactly how companies select services and technological components for their platforms and apps. This choice is also greatly influenced by the ‘experience’ of the integration, the Developer Experience, or ‘DX’. An increasing number of companies are building their integration and business layer functionality on the expansive public cloud serverless integration platforms, using tools such as Azure Logic Apps or AWS AppFlow, which has consequences for the design of your Developer Experience. ISAAC CTO Friso Geerlings elaborates on the developments and how digital service providers can anticipate this.

graphic developer achter computer programmeren

Today, many companies have – or are planning to have – digital services in place that perfectly suit the workflows of other companies. Examples of these are services for online payments, logistics, fraud detection, company or personal verification, insurance policies and credits or personalisation. However, to really enthuse companies about using these services in their own workflows, it is crucial to take into account developer experiences. However wonderful the product or service you provide, if it is too complex or unattractive for developers, you don’t stand a chance. After all, they will be integrating the services and products, and how they experience these processes will significantly affect their selection process of possible service providers. Consider it the importance of User Experience for technological products, as a good Developer Experience of technical and digital products is absolutely vital for success.

Six general rules for Developer Experience

So what exactly is it that defines a good Developer Experience? ISAAC has six general rules in place to assess and guarantee the quality and maturity of the Developer Experience of digital services:

  1. Simple experimentation: is an ‘explore and play’ Sandbox present and what is the extent to which it behaves like a production environment?
  2. The 3:30:3 principle: is it possible to grasp the exact function of the platform or service in 3 seconds, and can a test be carried out in 30 seconds, resulting in an initial valuable result in 3 minutes?
  3. Layered documentation: are developers and product owners quickly provided with the main information and are they also informed of the functionalities a platform or service provides and the value it adds? Scrum-teams have a different focus to specialised developers who ultimately carry out the integration, and this must be taken into account in your documentation.
  4. The API triad: which levels allow for interaction with the platform and the services? Is it limited to REST, or are Webhooks and GraphQL involved as well?
  5. Presence and findability: to what extent are the services with SDKs and plug-ins available in platform-specific marketplaces such as Magento, and on public cloud serverless integration platforms such as Azure or Amazon?
  6. Availability of information: is the information hidden on your own website, or is it publicly available on websites and in communities that feature many developers, such as Github and Stack Overflow?

The popularity of low code and ‘the quickest possible result’

The first general rules are usually quite easily translated into the to-dos for your digital services. They are easily controlled and depend on external developments only to a limited extent. If you have properly dealt with the aspects from the first four general rules, your Developer Experience as a service provider is basically set and ready to start, however this does not really anticipate the popularity of low code development or the wish for ‘the quickest possible result’. This is where the last two general rules come in.

Companies are increasingly building their integration and business layer functionality on large public serverless cloud integration platforms, also known as iPaaS (Integration Platform as a Service); consider Azure Logic Apps and AWS AppFlow. There is no longer any way around this for service providers, making it a matter of course to develop specific target platform SDKs and plugins in addition to your APIs. Continue by making them available on the marketplaces of these platforms, provided with the correct certification and documentation. In addition to the main cloud providers, also consider your position on more specialist platforms, such as the commerce environments of Magento, Salesforce Commerce Cloud, CommerceTools and WooCommerce.

The power of Azure Logic Apps and AWS AppFlow

A main advantage of visibility in these stores is the fact that this is the ultimate new place for companies to look for interesting integrations and connectors. Contrary to the on-premise integration platforms (such as Oracle, Apache Camel, Dell Boomi and IBM), for which connectors were usually available on protocol-level only, marketplace ecosystems emerge on the public cloud platforms on which service providers can immediately make their business service available – consider Stripe in Payments, an early actor on Azure.

It is hardly surprising that companies build or start building using workflow or data-services such as Azure Logic Apps or the emerging AWS AppFlow. Following are some advantages for companies that build their apps and architectures in this manner:

  • Azure and Amazon are cloud-based and serverless, meaning that their (network) infrastructure and workflows can be rolled out ‘as code’, are charged based on actual use, with hardly any management required. Platform users can shift their focus from technology to business;
  • Companies no longer have to worry about scalability, and the route to a successful deployment is easier. Azure DevOps supports the development process according to a standardised manner, for instance;
  • An entire ecosystem of training courses and certifications is available, making it easily accessible for training people;
  • So far, both Azure and AWS seem to take the curation of connectors and plug-ins seriously with clear guidelines, ensuring a quality baseline on integrations;
  • The pricing is attractive vis-à-vis on-premise integration platforms as well as pure low code platforms such as Mendix.

It may be clear that players such as Azure and AWS are fighting a fierce battle on all the above points to win the hearts of both businesses and developers, their invested billions blocking the paths of other players. As the provider of a service, this is a reality you must accept.

Consecutive steps

For many – or maybe most – service providers, focusing on being present on well-known platform specific marketplaces and the public cloud serverless integration platforms is a logical step, as is the development of SDKs and plugins on top of APIs to make available through these stores. Currently, this is the area of great opportunities. You should know that your ‘integration experience’ will be made available on an external platform, making it even more important to ensure all issues are perfectly designed according to the first four general rules to ultimately be successful through the public cloud serverless integration platforms.

How to proceed?

If you would like some more information about Developer Experience and the road to large cloud platforms, or exchange ideas and thoughts about your digital services, Rudy is happy to help!

Contact Rudy