In the second invited talk in our colloquium series in 2018, Alan Sill from Texas Tech University’s Cloud and Autonomic Computing Center shared his views on how to manage data centres the right way. In the talk «Topics in robust modern API design for data center control and scientific applications», many issues were pointed out whose proper solution will effect the whole cloud stack up to the way cloud-native applications are designed and equipped with deep self-management capabilities. Both the talk and the mixed-in debates are captured by this blog post.
How are cloud-native applications engineered? In contrast to the increasing popularity of the topic, there are surprisingly few reference applications available. In the previous blogpost we described a first version of a prototypical document management application consisting of composed containers which is called ARKIS Microservices. We elaborated on the challenges involved when designing and developing a cloud-native application. In addition, we showed some details about the architecture and functionalities of version 2.5 of this generic reference application .
In this blogpost, we now dive deeper into the architecture of the latest version 3.3, paying attention to each component. The document management software is a cloud-native application based on a microservices architecture. The software permits multiple tenants to manage their documents (create, read, update, delete and search patterns in documents). It manages the different tenants and offers different isolation models to store the documents of a tenant. Furthermore, the services are discoverable through declarative service descriptions, and their use is billed according to a pay-per-use scheme.
Service prototyping is still a young topic when it comes to cloud services, web services or other network services. Researchers are concerned with defining the topic more accurately and finding out which metrics matter, for instance time, quality or cost. New definitions, methods and tools will result from this process.
In a previous blog post, we have discussed the process of automating service and API prototyping tools on the scripting level, ensuring that all commands to install dependencies and to configure the software are executed properly, in order and without omission. The tool in focus has been Ramses which turns RAML web service descriptions into executable prototypes. The focus of this post is to take this idea further to the SaaS and web application level. A convenient web application, accessible from every browser, should offer a guided prototypical service generation based on just the service interface description which specifies its resources, methods and data types.
Rapid service prototyping, cloud application prototyping and API prototyping are closely related techniques which share a common goal: To get a first working prototype designed, implemented and placed online quickly, with small effort and with little headache over tooling concerns. The approaches in this area are still emerging and thus often ad-hoc or even immature. Several prototyping frameworks do nevertheless show a potential to become part of serious engineering workflows. In this post, the Ramses framework will be presented and evaluated regarding this goal.