Featured in Architecture & Design

Monal Daxini presents a blueprint for streaming data architectures and a review of desirable features of a streaming engine. He also talks about streaming application patterns and anti-patterns, and use cases and concrete examples using Apache Flink.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

At the microXchg microservices conference, held in Berlin, Adrian Cockcroft presented “Shrinking Microservices to Functions”. Key takeaways from the talk included: increases in network speed, the use of binary protocols, and configuration management and container technology has been an enabler for the deployment of applications consisting of multiple (micro)services; the opportunities provided by ‘serverless’ technologies promise further potential for running rapidly developed functions-as-a-service (FaaS) in the data center, at the edge, or on-premise; modern organisations need to be able to prototype and build applications at speed in order to deliver business value effectively; and the biggest challenges for modern enterprise software development are connected with the people and process within an organisation.

Cockcroft, VP Cloud Architecture Strategy at AWS, began his talk by discussing the state of software delivery ten years ago in relation to the capabilities that are available to engineers today. In the 90s and 2000s, the challenges of manually provisioning physical hardware meant that operations teams optimised the deployment process to involve as few artefacts as possible (potentially a single ‘monolithic’ application). This often led to the (accidental) creation of the ‘big ball of mud’ architecture antipattern.

Although the software development industry embraced Service Oriented Architecture (SOA) and the resulting WS-* standards in the 2000s, the previously mentioned trend towards minimising the number of deployable artefacts in combination with the 1Gbit/s limit on local area network (LAN) speed favoured the creation of large services with coarse-grained APIs that used a small number of SOAP/XML messages to communicate. In contrast, modern LANs network speeds can be as fast as 25Gbit/s, and the utilisation of efficient binary encoding protocols such as Avro, gRPC and simple binary encoding has improved efficiency of message interchange by at least two orders of magnitude.

The latest generation of AWS instances are connected with a 25Gbit/s network, not a 1Gbit/s network, and this in combination with the use of binary communication protocols, such as Avro and gRPC (and if you really want to get clever, simple binary encoding) [...] has been an enabler for the modern microservice architectural style

Approximately five years ago the “first wave of DevOps tooling” emerged, such as Chef and Puppet, which enabled the automated provisioning and configuration of hardware, and the continual deployment and upgrading of software. Cockcroft discussed that during his time at Netflix this style of ‘automated sysadmin’ was not adopted, and instead the Netflix team chose to embrace immutable infrastructure. At Netflix, coarse-grained application artefacts, such as pre-baked Amazon Machine Images (AMIs), could be programmatically associated with a virtual machine (VM) compute instance and placed in an dynamically scaling Auto Scale Group (ASG) behind a load balancer. This allowed the ‘update-in-place’ of application functionality, rather than deployment and upgrade via the manipulation of operating system (OS) primitives.

More recently, the emergence of the “second wave of DevOps” tooling such as container technology has further promoted the use of immutable infrastructure, and the technical characteristics of this OS-level virtualisation has enabled the much more rapid creation and instantiation of software system artefacts, taking deployment time from minutes to seconds. The widespread adoption of container technology and the de facto image standard created by Docker has also led to the creation of standardised resources. For example, many data store and middleware vendors provide official Docker images that contain their products pre-packaged and pre-configured for general usage.

Cockcroft suggested that the latest trend of ‘serverless’ or ‘function as a service’ (FaaS) technology is starting a further revolution within software development. The previous model of using VMs and containers to “deploy rapidly and run permanently” is now changing with the use of serverless technologies to “deploy rapidly and run (and pay) on demand”.

With the simplified programming model, deployment flexibility, and composability provided by a FaaS like AWS Lambda or Serverless, Cockcroft stated that entire systems can be rapidly prototyped and built. Technologies such as AWS Greengrass, which allow AWS Lambda functions to be run offline on Linux-based Internet of Things (IoT) devices, promise to further extend the reach and applicability of serverless technology “from the data center, to the edge, and also on-premise”.

With the rise of serverless technologies like AWS Lambda, where entire systems can be built within days, you have to ask yourself ‘should we invest in a lift and shift operation, or simply rebuild our current applications?’

Concluding his talk, Cockcroft suggested that many issues with modern enterprise software development are connected with the people and process within an organisation. Approaches such as the ‘inverse Conway maneuver’, and resources such as the Pheonix Project and DevOps Handbook can be used to drive transformational change. The microservice architectural style is a good compliment to the establishment of cross functional, autonomous, and highly aligned business units.

Microservices won’t work with organisational silos. With microservice development there should be high trust of development activities within an individual service boundary. Any potential low trust experienced between service providers should be mitigated with well-designed APIs and service level agreements (SLAs)