DEV Community: Sanket Barapatre

Introduction to Consumer Driven Contract Tests

Sanket Barapatre — Thu, 26 May 2022 18:49:19 +0000

CDCs short for Consumer Driven Contract Tests.

They involve writing test cases for other systems. These systems are the ones that we communicate with. Since their is a contract involved during event driven communication, it is highly imperative to ensure that this contract stays as it is even during feature developments, refactoring or any kind of code development on the other system.

Why we need CDCs

Lets say we our System A and we consume messages from System B using a contract. Since our functionality depends on System A.

We need to ensure that if System B unintentionally changes their code and the contract is affected, they KNOW that System A will fail since it will no longer be able to consume the messages/ event as the contract has been changed.

An effective way to ensure this is to write CDC or tests on our project that will be provided to System B to run. If during development of System B, they change this contract, and try to build it, the CDC by System A will fail and System B will know to rollback changes or to inform System A to take care of that change on our side. Hence, CDC helps to maintain proper communication between multiple Systems ensuring contract changes are properly communicated and maintained.

How to implement?

We write CDCs in our code base as simple as a JAVA Unit Test. These are then be wrapped into a docker image to be easily shared. This docker image can be shared via docker registry. The other System is informed that they have to run this CDC as we are using their contract.

Hence, they on their side, in their build pipeline, pull this docker image from registry and run it. If it runs successfully we know the contract is alive, if not, they need to inform us to incorporate the change.

If multiple Systems our consuming our contract, and we want to change it, we know whom to communicate the change to.

Some AWS Networking concepts

Sanket Barapatre — Thu, 26 May 2022 18:44:01 +0000

VPC is like a container for holding multiple resources together bound by a private CIDR. Can be cross AZs.
Subnet is sub-part of VPC for isolationg reources within VPC, like EC2 instance or DB.
VPC can have one CIDR, and each of its subnet use a part of it and all should be non overlapping.
VPC has security groups as firewall (which require config only for one way traffic, reply traffic is already configured) and route tables to connect to NAT, IG, or other VPC or even intra-traffic. Security Grp rules evaluated ascending first.
Subnet has its own route table, which inherits from VPC (basic one) if not specified, it has to have at-least intra-traffic by default. Subnet also have Network Access Control List as its own firewall where you have to configure for reply traffic as well unline VPC's security group. NACL rules are evaluated from ascending. Hence always add local traffic as first.
NAT- Network Address Translation, used when connecting VPC to outside world. It converts the internal IP address to public IP address.
Elastic IP- when we reboot an instance the public IP changes, hence we use Elastic IP to configure it to a static IP address.
IG- internet gateway to allow access to Internet. Has to configure same in route tables.
VPC peering- create a connection for connecting VPC -to-VPC.
NAT instance- a ec2 instance which is in public subnet and connected to a private subnet as well as NAT gateway for allowing private subnet to access outside world. We use similar setup for bastion host, or jump host to connect to private subnet DB.

RPC 1918 specification recommends us to use 10.0.0.0 or 172.168.0.0 similar CIDR for local CIDR when attaching to VPC.

Distributing and re-using your private maven artefact using github registry

Sanket Barapatre — Thu, 26 May 2022 18:40:39 +0000

The Why?

While working on a maven project or any other build tools like gradle, we come across a lot of dependencies while building a project.
The idea is to not write boilerplate plate and re-invent the wheel by utilizing existing dependencies in a project.
While working in an organization, we come across some libraries privately owned by the organization or something that we developed and want only specific teams or groups of people to use.

In order to share these build artefacts, such as for maven/gradle build tools, we can either share it using privately owned collaboration tools. But then the idea of updates, patches and improvements that needs to be done across teams for same artefacts become cumbersome and hard to maintain.

A simple idea is to upload the artefacts in a secure place where dependent services can download these using some credentials.

Here I will discuss 2 approaches to do this:

Github Registry Github provides a artefact registry where among other things you can build and deploy your artefact so it can be used by everyone as a public artefact or even privately owned. Here are the steps to do so:

a. create your library that you want to deploy

b. add distributionManagement attributes to your project object mode file, pom.xml specifiying which repository you want your code to be put into.

c. do mvn deploy to deploy your artifact as a dependency.

d. you should see your artifact deployed in corresponding package.

e. restrict the use of artefact by making your repo private, or you can keep it public. For private repos, you can use restrictions to specific users / user groups.

How to use above artefacts:

a. create a service depending on the library.

b. add remote repository attributes at pom.xml, specifying which remote repository where you can find above artefact.

c. in case your artefact is public, mvn compile or any of the goals should be able to download the dependency, a jar in our case.

d. for a private build artefact, we need to create a github access token with read-packages permission at least, so that we can use to download artefact.

e. with the gitub access token, updated in your settings.xml with id param matching with that of the remote repository tag, and provided you have access t the repo (at least read), mvn compile or similar goal should help you download the artefact.

S3 backed build artefact registry

We can use AWS S3 storage service to also store our artefacts securely. This helps you to maintain control over your artefacts in a finer way by specifying access policy, either limiting by VPC, or any other IAM policy.

Also, you can make it region specific, or have a S3 policy retrictive to same VPC as your build tool (like goCD, jenkins) so only your pipeline can build it. For local build, VPN to the VPC could help. This makes access secure, finer control over visibility to package and no modification for settings.xml.
1. For deploying artefacts to S3 bucket, we need a special dependency, namely maven-s3-wagon, this allows you to deploy maven artefact to s3 bucket.
2. Add distributionManagement attributes to your project object mode file, pom.xml specifiying which s3 bucekt you want your code to be put into. (we can have only single distributionManagement repo, at max 2 for snapshot and release separately)
3. Do mvn deploy to deploy your artifact as a dependency.
4. You should see your artifact deployed in corresponding package.
5. Restrict the use of artefact by making your repo private, or you can keep it public. for private repos, you can use restrictions to specific users / user groups.
For using above artefact:
1. specify your artefact s3 registry in remote repositories tag (we can have multiple remote repositories)
2. if your AWS credentials are configured, you should be able to download the dependencies , for mvn compile.

Both approaches are good enough with a little bit of tradeoff.
Github Registry is free and control can be given to specific users/ groups with read and write access.

Same For S3 bucket as registry, where you can control access via Virtual Private Network, to only some instances and maybe to some resources, principles.
S3 services depends on your AWS usage, but it is very inexpensive.

Comparing approaches

Github Registry puts your artefact closer to your code and has better visibility from code perspective. All code and dependency at one place.
While S3, gives you better security if you want existing IAM roles, policies applied to your artefacts as well.
Github Registry will throw error if you do not have write access while pushing or if above version already exists.
S3 Bucket will allow a authorizied push but overwrites previous artefact with same version.
You can check previous artefact in S3 bucket versions section, but it won't be downloadable by user directly.
This could be a major flaw if somebody tried to update same version. Could affect all users at once.

Both are highly available, and well performing service managing different versions, and proper updates being update.

AWS SQS with spring boot & Localstack with Junit Testing

Sanket Barapatre — Mon, 17 May 2021 09:31:02 +0000

Preface

Building microservices architecture often involves creating microservices communicating using a message bus or any means of loosely coupled means such as AWS Simple Queue Service, dearly called AWS SQS.

What are we building

Complete Code: spring-boot-localstack
Here is step-by-step guide of setting up a simple spring-boot web application talking to AWS SQS using localstack to mock the AWS environment.

This includes bare minimum configurations required to create a web app communicating using SQS only.

Basic Definitions:

localstack: Simply a tool to mock AWS Cloud Provider in your local environment, to help develop cloud applications.
Junit5: A testing framework for Java application based on Java8.
awaitability: A tool to express expectations for asynchronous system in an easy and concise manner.
Docker: Run any process or application in a containerised manner.

Pre-requisites:

Basic knowledge of Java and spring-boot.
Environment setup for running Docker e.g. docker for mac, or just a happy linux system
Can setup AWS CLI to play around with application. A command line utility to interact with AWS services.
A Familiar IDE.

Setup Basic Project

Get on to the second-best website on internet. Spring Initializer
Create a spring project preferably with 2.3 Spring boot version and following dependencies
- Spring web
- Lombok (java utility to avoid writing boilerplate code)
- AWS Simple Queue Service
Also add following dependencies externally in pom.xml

<dependency>
    <groupId>org.awaitility</groupId>
    <artifactId>awaitility</artifactId>
    <version>3.1.3</version>
    <scope>test</scope>
</dependency>

Create simple event and data models to send and receive messages:

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class SampleEvent {

  private String eventId;
  private String version;
  private String type;
  private ZonedDateTime eventTime;
  private EventData data;
}

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class EventData {

  private String name;
  private int age;
  private String description;
  private EventType eventType;

  public enum EventType {
    CREATED, PROCESSED
  }
}

Create a simple controller annotated with @SqsListener to listen to a queue.

@SqsListener(value = "${cloud.aws.sqs.incoming-queue.url}", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
  private void consumeFromSQS(SampleEvent sampleEvent) {
    log.info("Receive message {}", sampleEvent);
    //do some processing
    sampleEvent.setEventTime(ZonedDateTime.now());
    sampleEvent.getData().setEventType(EventData.EventType.PROCESSED);
    amazonSQSAsync.sendMessage(outgoingQueueUrl, mapper.writeValueAsString(sampleEvent));
  }

Spring property configurations:

setup application.yml with aws sqs properties, such as:

localstack:
  host: localhost

cloud:
  aws:
    credentials:
      access-key: some-access-key
      secret-key: some-secret-key
    sqs:
      incoming-queue:
        url: http://localhost:4576/queue/incoming-queue
        name: incoming-queue
      outgoing-queue:
        name: outgoing-queue
        url: http://localhost:4576/queue/outgoing-queue
    stack:
      auto: false
    region:
      static: eu-central-1

logging:
  level:
    com:
      amazonaws:
        util:
          EC2MetadataUtils: error

Notes:
a. Aws credentials can also be set up environmental variables or in a .aws/credentials file, (further read 😉)
b. define name and url of queues so application can listen to and write to queue. Localstack runs SQS service on port number: 4576
c. The below logging property is to avoid having multiple lines of error where application tries to connect to EC2 instance of localstack. (workaround 😏)

AWS Local SQS configs:

Inside the java configuration for SQS we create some beans to allow our application to talk to SQS service provided by localstack. You could add a profile for each config when deploying app in production i.e. actual AWS environment.

@Bean
//endpoint config for connecting to localstack and not actual aws environment.
  public AwsClientBuilder.EndpointConfiguration endpointConfiguration(){
    return new AwsClientBuilder.EndpointConfiguration("http://localhost:4576", region);
  }

  @Bean
  @Primary
//This bean will be used for communicating to AWS SQS
  public AmazonSQSAsync amazonSQSAsync(final AwsClientBuilder.EndpointConfiguration endpointConfiguration){
    AmazonSQSAsync amazonSQSAsync = AmazonSQSAsyncClientBuilder
        .standard()
        .withEndpointConfiguration(endpointConfiguration)
        .withCredentials(new AWSStaticCredentialsProvider(
            new BasicAWSCredentials(awsAccesskey, awsSecretKey)
        ))
        .build();
    createQueues(amazonSQSAsync, "incoming-queue");
    createQueues(amazonSQSAsync, "outgoing-queue");
    return amazonSQSAsync;
  }
//create initial queue so our application can talk to it
  private void createQueues(final AmazonSQSAsync amazonSQSAsync,
                            final String queueName){
    amazonSQSAsync.createQueue(queueName);
    var queueUrl = amazonSQSAsync.getQueueUrl(queueName).getQueueUrl();
    amazonSQSAsync.purgeQueueAsync(new PurgeQueueRequest(queueUrl));
  }

We can use QueueMessagingTemplate for sending and receiving messages from AWS SQS

 @Bean
  public QueueMessagingTemplate queueMessagingTemplate(AmazonSQSAsync amazonSQSAsync){
    return new QueueMessagingTemplate(amazonSQSAsync);
  }

Also setup QueueMessageHandlerFactory so it can convert incoming messages from SQS as String to the actual object you want, in this case Simple Event, using objectmapper.
You can configure objectmapper separately. Add your custom deserialiser o such by registering your module or add custom datetime conversion.

@Bean
  public QueueMessageHandlerFactory queueMessageHandlerFactory(MessageConverter messageConverter) {

    var factory = new QueueMessageHandlerFactory();
    factory.setArgumentResolvers(singletonList(new PayloadArgumentResolver(messageConverter)));
    return factory;
  }

  @Bean
  protected MessageConverter messageConverter(ObjectMapper objectMapper) {

    var converter = new MappingJackson2MessageConverter();
    converter.setObjectMapper(objectMapper);
    // Serialization support:
    converter.setSerializedPayloadClass(String.class);
    // Deserialization support: (suppress "contentType=application/json" header requirement)
    converter.setStrictContentTypeMatch(false);
    return converter;
  }

Finally add this docker compose yaml asking docker to create a localstack container:

version: '3.0'

services:
  localstack:
    image: localstack/localstack:0.10.7
    environment:
      - DEFAULT_REGION=eu-central-1
      - SERVICES=sqs
    ports:
      - "4576:4576"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"

Starting the application

start the localstack using: docker-compose up (in same directory as docker file)
run application using: mvn spring-boot:run
send a message to sqs using AWS CLI for e.g.:

aws --endpoint="http://localhost:4576" --region=eu-central-1 sqs send-message --queue-url http://localhost:4576/queue/incoming-queue --message-body '{
  "eventId": "some-event-id-1",
  "eventTime": "2016-09-03T16:35:13.273Z",
  "type": "some-type",
  "version": "1.0",
  "data": {
    "name": "Dev. to",
    "age": 20,
    "description": "User created",
    "eventType": "CREATED"
  }
}'

You should see log messages of event received and forwarded.
Also added a Junit Test which uses same configuration as for local run.

Thank you!!

Getting Asynchronous with SQS and SNS

Sanket Barapatre — Mon, 17 May 2021 03:52:15 +0000

Preface

Developing microservices architecture is a really good way to ensure that we get independently deployable which are easier to manage, scalable, develop and are fault tolerant.

A business functionality is generally achieved using meaningful and validated communication between multiple microservices which in-turn interact with their respective databases systems persisting meaningful state.

The Why

To think of its disadvantages, about the bottle-neck and the points of failure, we can pin point several areas including:

microservices failure to process due to business logic not updated, request validation failure, unhandled conditions, faulty business logic, internal feature disabled, also including failure in its internal connection to database
availability of microservice due to restarts, re-deployment on the microservice. e.g. pod restarts, new features or enhancement deployed in a microservice.

Having synchronous communication between such microservices could be dangerous if

Any deployed microservice restarts, or is re-deployed.
High latency, network failure in reaching the microservice or a general non-availability of such microservice.

A chain of REST API calls from microservice to another one, could lead to ultimate failure of the execution of the corresponding business functionality.

The What

In order to ensure a relaxation to microservices so that they can restart, take time to respond to a REST API call, one way is to make the architecture loosely coupled and have them talk to each other using events rather than typical request-response HTTP calls.

HTTP calls can timeout occasionally due to network failure, high latency, or microservice being re-loaded, rate limit exceeding on microservices or some other general downtime of a microservice.

The How

Such a simple mechanism to achieve is by using, SQS AWS Simple Queue Service and Simple Notification Service as means of communication.
In a nutshell,

A microservice sends out a meaningful and short message to a SNS topic.
A SNS topic can be subscribed to send message to various SQS listened by each microservice. Hence fan-out of a message.
A microservice can listen to an incoming message using a SQS listener module.

Such a system ensures easy fault tolerance as well, since we can monitor the complete flow of message generation from source, to final consumption by a microservice.

The Benefits

Traceability & Fault Tolerance

Ensuring traceability by using following properties in the envelope of a message,

eventId: each message (or event) generated by a microservice has a unique id, preferably UUID which ensures uniqueness of a event and store it.
traceId: Each business flow involves multiple messages generation in a single flow, e.g. place order, cart checkout, payment processing, order placed. Such a flow that generates a message in response to an incoming message, can have same traceId for all messages so that a complete flow can be traced. A traceId is generated at source and is passed on to new messages generated as a result.
spanId: a spanId is similar to a traceId except it need not cover all messages. It is an additional safety net that spans over two events, which are linked together. e.g. if a microservice consumes a message A and sends out message B, they have same spanId, so we know these messages are linked.
version: every message that we consume can have a version. In case of a breaking change in a message, we could upgrade the version allowing it to be processed differently and also enable version as a means of comunication breaking, major or even minor changes in an event.
context: the business context which gives a rough idea and a meaning to the event. Suppose, ORDER_PROCESSING, could be a business context for the flow for messages that cover messages where customer selects means of payment, processing of actual payment happens and updating status of payment.

This is how an event can look like:

{
"eventId":"518c9aac-b6b9-11eb-b34e-8f1bd39e6f13",
"traceId":"57df4c56-b6b9-11eb-a0a2-f72362d4cbcb",
"spanId":"5e9245a8-b6b9-11eb-9ced-935329a9daeb",
"version":"1.1.0",
"context":"ORDER_PROCESSING",
"data":{
        "name":"customer name",
        "items":"I bought this"
    }
}

Testable

Having SQS and SNS as a means of event driven communication ensures testability since each microservice is a black box consuming a message and producing another. Hence multiple scenarios can be tested using different incoming messages and testing various outgoing message.
Also, AWS provides a means of sending a test message in SNS, or SQS so that we can test a deployed application as well as replay some messages which may have failed.

Flexibile with microservice availability:

Introducing DLQs: Dead Letter Queues

A microservice can have some downtime, and all the messages that it was supposed to consume can be stored in a AWS SQS. Once the service is up, it can start consuming messages from where it left off and keep on working.
If a microservice takes time to load, then messages from SQS after being replayed for a configurable number of times, is send to a Dead Letter Queue (or DLQ).
This DLQ stores all failed messages and can be pushed back to the main queue to replay it.
Also in case if a microservice is not able to process a message due to feature currently not available, message is broken or invalid, then such a message is retried and pushed back to the DLQ. Here, we can later analyse the message and update how we handle this message in our microservice.

Conclusion

Having asynchronous communication using AWS Simple Queue Service and SNS Simple Notifications service makes microservices de-coupled and an easy way to have Event Driven Architecture with event as means of communication.

DEV Community: Sanket Barapatre

Introduction to Consumer Driven Contract Tests

CDCs short for Consumer Driven Contract Tests.

Why we need CDCs

How to implement?

Some AWS Networking concepts

Distributing and re-using your private maven artefact using github registry

AWS SQS with spring boot & Localstack with Junit Testing

Preface

What are we building

Basic Definitions:

Pre-requisites:

Setup Basic Project

Create simple event and data models to send and receive messages:

Create a simple controller annotated with @SqsListener to listen to a queue.

Spring property configurations:

AWS Local SQS configs:

Starting the application

Getting Asynchronous with SQS and SNS

Preface

The Why

The What

The How

The Benefits

Traceability & Fault Tolerance

Testable

Flexibile with microservice availability:

Conclusion

Further Reading