Tag Archives: Microservice

Testing a Microservice Architecture with Docker and Compose


via Testing a Microservice Architecture with Docker and Compose.

This post originally appeared on the Standard Treasury Engineering Blog, here. It has been re-published here with permission.

Today I’d like to talk about software testing – a subject dear to my heart. In particular, I’d like to talk about testing a modern microservice architecture, using Standard Treasury’s software stack as an example.

Let’s begin with my assertion that this is a both hard and unsolved problem. If you disagree with that, I’d love to talk to you about what you know that I don’t. That’s a serious offer, by the way.

Okay.

I’m going to begin at the beginning and work my way up.

Building a Microservices-based REST API with RestExpress, Java EE, and MongoDB: Part 2


Develop a well-architected and well-documented REST API, built on a tightly integrated collection of Java EE-based microservices. Note: All code available on GitHub. For the version of code that matches the details in this blog post, checkout the master branch, v1.0.0 tag (after running git clone …, run a ‘git checkout tags/v1.0.0’ command). Previous Post In […]

https://programmaticponderings.wordpress.com/2015/05/31/building-a-microservices-based-rest-api-with-restexpress-java-ee-and-mongodb-part-2/

Building a Microservices-based REST API with RestExpress, Java EE, and MongoDB: Part 3


Develop a well-architected and well-documented REST API, built on a tightly integrated collection of Java EE-based microservices.

https://programmaticponderings.wordpress.com/2015/06/05/building-a-microservices-based-rest-api-with-restexpress-java-ee-and-mongodb-part-3/

Microservice Design Patterns


via Microservice Design Patterns – Miles to go 2.0 ….

The main characteristics of a microservices-based application are defined in Microservices, Monoliths, and NoOps.  They are functional decomposition or domain-driven design, well-defined interfaces, explicitly published interface, single responsibility principle, and potentially polyglot. Each service is fully autonomous and full-stack. Thus changing a service implementation has no impact to other services as they communicate using well-defined interfaces. There are several advantages of such an application, but its not a free lunch and requires a significant effort in NoOps.