Trifork Blog

Exposing asynchronous communication through a synchronous REST API with Spring 5

16:02 on April 13th, 2018 by
No Comments

Author – Erwin de Gier

On my current project, we opted not to use REST for the communication between our services. Instead we make use of AxonIQ’s AxonHub, which acts as a specialized message broker. Messages can be of three types:

  • Command – You want to change something
  • Event – You want to inform others of something that happened
  • Query – You want to know something

The communication is asynchronous and we also have to deal with eventual consistency. If we would create an order by sending a CreateOrderCommand, this order would result in various events which update the state of the Order. We then need to send a query, of which we also receive the result asynchronous.

Our web and mobile frontend communicate with a microservices backend through a REST API. When the user creates an order (clicks the ‘buy’ button), they expect a result immediately. For both frontends, an API which models this user experience closely makes the most sense. This means that we want a more synchronous API, where we send a ‘create order’ request and immediately receive a response.

We implemented this using a small REST facade which translates our asynchronous communication in the backend to the synchronous communication for the frontend. This is a good use case for Spring 5’s reactive Webflux and Project Reactor. Using Project Reactor’s reactive API makes it possible to combine multiple asynchronous calls and operate on their result. Webflux handles the conversion of the reactive types (Mono, Flux) to REST responses. It optimizes the use of threads; by writing non-blocking code, we can reuse threads between asynchronous calls for handling other requests.

Diagram 1 gives us an overview of this approach.

Diagram 1

 

Implementation

Let’s have a more detailed look at the code for the create order example. Listing 1 shows the (slightly) simplified implementation of our REST controller method.

@PostMapping
public Mono<ResponseEntity<OrderResponse>> createOrder(CreateOrderRequest request) 
{
 CreateOrderCommand command = CreateOrderCommand.fromRequest(request); //1

 return this.commandGateway.send(command) //2
  .flatMap(id -> queryGateway.send(new FindOrderSummaryQuery(id))) //3
  .retryWhen(errors -> errors.delayElements(Duration.of(100, MILLIS)) //4
  .take(10)).concatWith(Mono.error(new RuntimeException())).next() //5
  .onErrorReturn(new OrderResponse(orderID, OrderStatus.CREATED)) //6
  .map(orderResponse -> ResponseEntity.ok().body(orderResponse)); //7
}

Listing 1

We first create a command out of the REST request (line 1). A command is a message with the specific intent to change something in our domain. In this specific case, we want to create a new order.

After creating the command, the two asynchronous calls we make are:

Mono<String> id = this.commandGateway.send(command);

and:

Mono<OrderResponse> orderResponse = queryGateway.send(new FindOrderSummaryQuery(id));

Both calls return a single value by using a Mono. A Mono is a reactive type, comparable to the Java’s CompletableFuture. It has zero or one element and can represent an error. As with all reactive types, the value (or error) is delivered over time.

The second call takes the result of the first call as its input. We need the returned id of the command to query for the order. We use the flatMap operator to achieve this (line 3). The flatMap takes the asynchronous result of call 1 and passes this as a parameter to the lambda of call 2. The callback version can be seen in Listing 2: notice the nested lambda, which makes the code complex and less readable.

this.commandGateway.send(command, id -> {
  queryGateway.send(new FindOrderSummaryQuery(id));
});

Listing 2

There is a delay between sending the command and being able to query the result. When the created order cannot be found (e.g. it isn’t create yet or something has gone wrong), an exception is thrown. In this chain, this is represented as a Mono.error(throwable). We use the retryWhen method to retry the query (line 4). We do this 10 times with a delay of 100 ms. When we still don’t get a result, we throw an error (line 5). We don’t expose the error to the client, but pass an OrderResponse with the id and status CREATED (line 6). The client can then query the status of the order later by using this id. This is a form of graceful degradation.

Finally we map the order response from the query to a response entity which can be returned by Spring. Spring actually subscribes to this whole chain and sends out the REST response for us.

Conclusion

Spring 5 and Project Reactor allow us to handle asynchronous communication with concise and readable code. We can do retries, error handling and the combination of multiple asynchronous calls in just a few lines.
The integration of Webflux with Project Reactor allows the use of reactive paradigms in a REST controller. Webflux uses an asynchronous approach. While we wait for a backend query to return, we don’t block the main thread. this allows it to be used for other requests.
Our specific use case is a good example of one of the applications of Spring 5 Webflux and Project Reactor.

Tags: , , , ,

Posted in: Custom Development | Spring

Refactoring from Elasticsearch version 1 with Java Transport client to version 6 with High Level REST client

9:00 on February 27th, 2018 by
No Comments

Every long running project accrues technical debt. It may be that the requirements today have evolved in a different direction from what was foreseen when the project was designed, or it may be that difficult infrastructure tasks have been put off in favor of new functionality. From time to time, you need to refactor your code to clean up this technical debt. I recently finished such a refactoring task for a customer, so in the category ‘from the trenches’, I would like to share the story here.

Elasticsearch exposes both a REST interface and the internal Java API, via the binary transport client, for connecting with the search engine. Just over a year ago, Elastic announced to the world that it plans to deprecate the transport client in favor of the high level REST client, “as soon as the REST client is feature complete and is mature enough to replace the Java API entirely”. The reasons for this are clearly explained in Luca Cavanna’s blogpost, but the most important disadvantage is that using the transport client, you introduce a tight coupling between your application and the exact major and minor release of your ES cluster. As long as Elasticsearch exposes its internal API, it has to worry about breaking thousands of applications all over the world that depend on it.

The “as soon as…” timetable sounds somewhat vague and long term, but there may be good reasons to migrate your search functionality now, rather than later. In the case of our customer, their reason is wanting to use the AWS Elasticsearch service. The entire codebase is already running in AWS, and for the past few years they have been managing their own Elasticsearch cluster running in EC2 instances. This turns out to be labor intensive when updates have to be applied to these VMs. It would be easier and probably cheaper to let Amazon manage the cluster. As the AWS Elasticsearch service only exposes the REST API, the dependence on the transport protocol will have to be removed.

Action plan

The starting situation was a dependency on Elasticsearch 1.4.5, using the Java API. The goal was the most recent Elasticsearch version available in the Amazon Elasticsearch Service, which at the time was 6.0.2, using the REST API.

In order to reduce the complexity of the refactoring operation, we decided early on, to reindex the data, rather than trying to convert the indices. Every Elasticsearch release comes with a handy list of breaking changes. Looking through this list, we tried to make a list of breaking changes that would likely affect the search implementation of our customer. There are more potential breaking changes than listed here, but these are the ones that an initial investigation suggested might have an impact:

1.x – 2.x:

  • Facets replaced by aggregations
  • Field names can’t contain dots

2.x – 5.x:

5.x – 6.0:

  • Support for indices with multiple mapping types dropped

The plan was first to convert the existing code to work with ES 6, and only then migrate from the transport client to the High Level REST client.

Implementation 

The entire search functionality, originally written by our former colleague Frans Flippo, was exhaustively covered by unit- and integration tests, so the first step was to update the maven dependency to the current version, run the tests, and see what broke. First there were compilation errors that were easily fixed. Some examples:

Replace FilterBuilder with QueryBuilder, RangeFilterBuilder with RangeQueryBuilder, TermsFilterBuilder with TermsQueryBuilder, PercolateRequestBuilder with PercolateQueryBuilder etc, switch to HighlightBuilder for highlighters, replace ‘fields’ with ‘storedFields’. The count API was removed in version 5.5, and its use had to be replaced by executing a search with size 0. Facets had already been replaced by aggregations by our colleague Attila Houtkooper, so we didn’t have to worry about that.

In ES 5, the suggest API was removed, and became part of the search API. This turned out not to have an impact on our project, because the original developer of the search functionality implemented a custom suggestions service based on aggregation queries. It looks like he wanted the suggestions to be ordered by the number of occurrences in a ‘bucket’, which couldn’t be implemented using the suggest API at the time. We decided that refactoring this to use Elasticsearch suggesters would be new functionality, and outside the scope of this upgrade, so we would continue to use aggregations for now.

Some updates were required to the index mappings. The most obvious one was replacing ‘string’ with either ‘text’ or ‘keyword’. Analyzer became search_analyzer, while index_analyzer became analyzer.

Syntax ES 1:

"fields": {
    "analyzed": {
        "type": "string",
        "analyzer" : "dutch",
        "index_analyzer": "default_min_word_length_2"
    },
    "not_analyzed": {
        "type": "string",
        "index": "not_analyzed"
    }
}

Syntax ES 6:

"fields": {
  "analyzed": {
    "type": "text",
    "search_analyzer": "dutch",
    "analyzer": "default_min_word_length_2"
  },
  "not_analyzed": {
    "type": "keyword",
    "index": true
  }
}

Document id’s were associated with a path:

"_id": {
    "path": "id"
},

The _id field is no longer configurable, so in order to have document ids in Elasticsearch match ids in the database, the id has to be set explicitly, or Elasticsearch will generate a random one.

All in all, it was roughly a day of work to get the project to compile and ready to run the unit tests. All of them were red.

Running Elasticsearch integration tests

The integration tests depended on a framework that spun up an embedded Elasticsearch node, to run the tests against. This mechanism is no longer supported. Though with some effort it is still possible to get this to work, the main point of the operation was to move the search implementation back into ‘supported’ territory, so we decided to abandon this approach.

First we tried out the integration test framework offered  by Elasticsearch: ESIntegTestCase. Unfortunately, this framework turns out to be highly opinionated. It wants the tests to run under the RandomizedRunner, which is also used to test Lucene. In order to work with the ESIntegTestCase, we would have had to partially rewrite most of the existing integration tests. Ideally, you can rely on the unit tests to prove that your refactoring preserved the expected functionality. If you have to change the tests, you run the risk that you end up ‘fixing’ a test to make it green. We decided to go with the Elasticsearch maven plugin instead, which required no code changes to the tests other than configuring the ES client.

<plugin>
    <groupId>com.github.alexcojocaru</groupId>
    <artifactId>elasticsearch-maven-plugin</artifactId>
    <version>6.0</version> <!--Plugin version-->
    <configuration>
        <clusterName>testCluster</clusterName>
        <transportPort>9500</transportPort>
        <httpPort>9400</httpPort>
        <version>6.0.2</version> <!--Elasticsearch version-->
        <timeout>20</timeout>
    </configuration>
    <executions>
        <execution>
            <id>start-elasticsearch</id>
            <phase>pre-integration-test</phase>
            <goals>
                <goal>runforked</goal>
            </goals>
        </execution>
        <execution>
            <id>stop-elasticsearch</id>
            <phase>post-integration-test</phase>
            <goals>
                <goal>stop</goal>
            </goals>
        </execution>
    </executions>
</plugin>

That’s all there is to it. With this configuration, when maven enters the pre-integration test phase, the plugin starts a single node elasticsearch cluster of version 6.0.2 in a new process, listening to ports 9500 and 9400, runs the tests, and then stops the cluster and cleans up. The plugin allows a more fine grained configuration of the cluster, including ES plugins, but we were trying to replace a simple embedded ES node, so this was unnecessary. Now all the tests were yellow: the project compiles, tests run and assertions fail.

Fixing the pitfalls

Some search results were missing data. In version 1.x, fields added to your query were retrieved from the _source field, and returned in your search result. Where we replaced these with storedFields, the fields in question had to be explicitly marked as stored fields in the mapping. Fields that are not stored, are included in your search, but not returned in the search result. This can be useful in queries where you want to retrieve just a few fields from a large document.

Some aggregations were failing with the message ‘Fielddata is disabled on text fields by default’. In ES 1, there were ‘string’ fields, not ‘text’ and ‘keyword’ fields. By default, operations like sorting and aggregations are not allowed on ‘text’ fields, unless you explicitly mark the field as such, with “fielddata”:true. This is generally not a good idea on analyzed fields, as it can cause a substantial performance hit, and may return results you were probably not expecting. We decided to use “copy_to” to make ‘keyword’ type copies of the fields in question to run the aggregations on.

It seems that ES 1.4 supported the java regex engine, while ES 6.x uses a different one, which doesn’t support boundary matchers such as \b. Luckily there was a workaround, which should work in most cases.

In the REST API, a query field can be boosted with a caret: “fields”:[ “title^5”]. In this search implementation based on the transport client, this was implemented by appending ^ and the boost to the field name: “title^”+titleBoost. In ES 6, this approach no longer seemed to work. There was a  clear difference in results between a query through the Java API, and executing the exact same query, via the toString() method of the QueryBuilder, using the REST API. The correct approach is myQueryStringQueryBuilder.field(fieldName, boost). Because the query looked fine in the console, and worked fine when copied and run against the REST API, this pitfall was not immediately obvious.

Differences in search results

A fair number of the tests failed because the order of search results by relevance had changed between ES 1 and 6. From the way the tests were written, we got the impression that in ES 1, documents with the exact same score were returned in the order in which they were indexed, while in ES 6, this doesn’t seem to be the case. We could have made the tests ‘green’, by adding an additional sort by id after the _score, which would make the test perform consistently over our tiny artificial test data set, but this didn’t ‘feel’ right. We didn’t find an explicit mention of this behavior in the documentation, or any change over ES versions, and there wasn’t a good use case for it. The numerical value of the document id has no special relevance to the users. In real world data, search results with the exact same _score would probably be exactly equally relevant, and the customer agreed with us not to second guess Elasticsearch and Lucene on the matter of search result relevance.

A more interesting issue was a test where documents that looked more relevant to us, were now getting a lower score than seemingly less relevant ones. The tiny data set for these tests contained a large number of mentions of the search term in the queries. Somehow, documents that contained an additional, boosted, field that matched the search term, were scoring lower than an otherwise identical document where one of those fields was left blank. The weight of a search term is the product of a function that combines the term frequency, the inverse document frequency and the boost on a field. Artificially packing a document with more mentions of the search term was actually making a match on this search term less relevant to Lucene. We could have spent considerable time tweaking the queries to make documents in our very artificial test data set equally relevant to ES 6 as they were to ES 1, but the customer agreed with us that this wasn’t the way to go. Considerable effort in the development of search engines goes into making search results more relevant. It seemed like a good idea to trust the experts at Elastic and Lucene when it comes to search result relevance, so the customer agreed we shouldn’t spend a lot of time trying to replicate the behavior of a more primitive version of the search engine, fine tuned to a tiny, artificial test data set. All tests were now green. On to the next stage.

Migrating to the High Level REST Client

In order to work with the Amazon Elasticsearch Service, we had to remove the dependence on the transport client. In the long term, this is a good idea anyway, as Elastic intends to deprecate and ultimately remove this client. In order to facilitate the move away from the transport client, ES has been working on the so called High Level REST Client. This client uses the low level REST client to send requests, but accepts the existing query builders from the Java API, and returns the same response objects. At least in theory, this should allow you to move your search functionality to the new client with minimal code changes. When it came to searching, practice matched this theory quite nicely. Here is a pseudocode representation of the syntax using the transport client:

// Query
SearchRequestBuilder searchRequestBuilder = client.prepareSearch(indexName);
searchRequestBuilder.setTypes(objectType);
searchRequestBuilder.setQuery(buildMainQuery(formObject));

// Paging
searchRequestBuilder.setFrom(maxSize * formObject.getPage());
searchRequestBuilder.setSize(maxSize);

// Fields to return
for (String field : formObject.getRequestedFields()) {
    searchRequestBuilder.addStoredField(field);
}

// Filters
searchRequestBuilder.setPostFilter(buildFilterQuery(formObject));

// Sorting
searchRequestBuilder.addSort(formObject.getSortField(), toSortOrder(formObject.getSortOrder()));

(...)

SearchResponse searchResponse = searchRequestBuilder.execute().actionGet();

And here is the syntax using the High Level REST Client

// Query
SearchSourceBuilder sb = new SearchSourceBuilder();
sb.query(buildMainQuery(formObject));

// Paging
sb.from(maxSize * formObject.getPage());
sb.size(maxSize);

// Fields to return
sb.storedFields(asList(formObject.getRequestedFields()));

// Filters
sb.postFilter(buildFilterQuery(formObject));

// Sorting
sb.sort(formObject.getSortField(), toSortOrder(formObject.getSortOrder()));

SearchRequest request = new SearchRequest(indexName);
request.types(objectType);
request.source(sb);

(...)

SearchResponse searchResponse = client.search(searchRequest);

 

The query builders were accepted as they were, and the search response object was the same. We ran the tests, and they were still green. The search service no longer depended on the transport client. For indexing operations, the conversion was similarly straight forward:

BulkRequestBuilder indexBulkRequestBuilder = client.prepareBulk();
(...)
IndexRequestBuilder indexRequestBuilder = client.prepareIndex(indexName, objectType);
indexRequestBuilder.setId(domainObject.getId());
String json = jsonConverter.convertToJson(domainObject);
indexRequestBuilder.setSource(new BytesArray(json), XContentType.JSON);
indexBulkRequestBuilder.add(indexRequestBuilder);
(...)
BulkResponse response = indexBulkRequestBuilder.execute().actionGet();

And with the Low level REST client:

BulkRequest bulkRequest = new BulkRequest();
(...)
IndexRequest indexRequest = new IndexRequest();
String json = jsonConverter.convertToJson(domainObject);
indexRequest.index(indexName);
indexRequest.id(domainObject.getId());
indexRequest.source(new BytesArray(json), XContentType.JSON);
indexRequest.type(objectType);
bulkRequest.add(indexRequest);
(...)
BulkResponse response = client.bulk(bulkRequest);

Now for the admin operations that manage indices. In our target release of Elasticsearch, 6.0.2, the indices API was not yet supported. In the current release (6.2 at the time of writing this blog), there is support for this, so at first we tried using the 6.2 version of the ES libraries, against a cluster running 6.0.2. This turned out to break the search functionality. The 6.2 version of the query builders was including keywords in some queries, that were not yet supported in 6.0. Elastic had warned about this in their announcement mentioned earlier:

“… the high-level client still depends on Elasticsearch, like the Java API does today. This may not be ideal, as it still ties users of the client to depend on a certain version of Elasticsearch, but this decision allows users to migrate away more easily from the transport client. We would like to get rid of this direct dependency in the future, but since this is a separate long-term project, we didn’t want this to affect the timing of the client’s first release.”

As the High Level REST Client implementation wasn’t directly compatible with the admin operations in our application anyway, we decided to just implement these features using the Low Level REST client. Here is an example of creating an index template using the transport client

String template = readFile(templateFileName);

elasticClient.admin()
            .indices()
            .preparePutTemplate(indexName)
            .setPatterns(indexNamePattern)
            .setSource(new BytesArray(template), XContentType.JSON)
            .get();

And here is the same operation using the low level REST client:

String template = readFile(templateFileName);

HttpEntity entity = new NStringEntity(template, ContentType.APPLICATION_JSON);

client.performRequest("PUT", "_template/" + templateName, emptyMap(), entity);

The index name pattern now had to be included in the template JSON and was no longer dynamically configurable in the code, but this was not a problem for our application. With all the tests nice and green, the project was done!

Conclusion

Software problems always seem easy once you know how to solve them. This report from the trenches may give the impression that this was a simple, straight forward migration that only took a few days, but in reality the whole project involved several weeks of investigation, backtracking from dead ends, and a lot of trial and error. Hopefully, this blog can help fellow Java developers who are tasked with the same problem save a lot of time, or you could contact Trifork to provide a helping hand.

Posted in: Custom Development | Elasticsearch | From The Trenches

Deep Learning for Natural Language Processing – Part II

17:36 on January 15th, 2018 by
No Comments

Author – Wilder Rodrigues

Wilder continues his series about NLP.  This time he would like to bring you to the Deep Learning realm, exploring Deep Neural Networks for sentiment analysis.

If you are already familiar with those types of network and know why certain choices are made, you can skip the first section and go straight to the next one.

I promise the decisions I made in terms of train / validation / test split won’t disappoint you. As a matter of fact, training the same models with different sets got me a better result than those achieved by Dr. Jon Krohn, from untapt, in his Live Lessons.

From what I have seen in the last 2 years, I think we all have already been through a lot of explanations about shallow, intermediate and deep neural networks. So, to save us some time, I will avoid revisiting them here. We will dive straight into all the arsenal we will be using throughout this story. However, we won’t just follow a list of things, but instead, we will understand why those things are being used.
Read the rest of this entry »

Tags: , , ,

Posted in: Machine Learning

Deep Learning for Natural Language Processing – Part I

13:11 on January 3rd, 2018 by
No Comments

Author – Wilder Rodrigues

Nowadays, the task of natural language processing has been made easy with the advancements in neural networks. In the past 30 years, after the last AI Winter, amongst the many papers have been published, some have been in the area of NLP, focusing on a distributed word to vector representations.

The papers in question are listed below (including the famous back-propagation paper that brought life to Neural Networks as we know them):
Read the rest of this entry »

Tags: , , , , , , , ,

Posted in: Machine Learning

How to manage Database Migrations with Flyway?

15:01 on December 5th, 2017 by
No Comments

Joris Kuipers, CTO at Trifork, presented a webinar on some usage patterns for Flyway. You can find the recording on our Trifork YouTube channel.

Tools like Flyway address a common concern for many people, which quickly leads to questions on how to pick a tool and then apply it in the best manner for one’s particular situation.

In this blog post, Joris has summarized the Q&A session – he provides the readers with his answers and ideas for managing database migrations.

1. How does Flyway compare to Liquibase?

When I was choosing a DB schema migration tool 4 or 5 years ago, I’ve looked at both Liquibase and Flyway. In general, I’d say that Flyway is a bit more light-weight: Liquibase addresses some requirements that Flyway explicitly chooses not to support. These include support to define migrations declaratively (e.g. in XML) and then generate the correct SQL DDL statements for your particular DBMS and the support to generate migration rollbacks (countering operations).
Read the rest of this entry »

Tags: , , , , ,

Posted in: Custom Development

Using Axon with PostgreSQL without TOAST

9:05 on October 9th, 2017 by
No Comments

The client I work for at this time is leveraging Axon 3. The events are stored in a PostgreSQL database. PostgreSQL uses a thing called TOAST (The Oversized-Attribute Storage Technique) to store large values.

From the PostgreSQL documentation:

“PostgreSQL uses a fixed page size (commonly 8 kB), and does not allow tuples to span multiple pages. Therefore, it is not possible to store very large field values directly. To overcome this limitation, large field values are compressed and/or broken up into multiple physical rows”

As it happens, in our setup using JPA (Hibernate) to store events, the DomainEventEntry entity has a @Lob annotation on the payload and the metaData fields (via extension of the AbstractEventEntry class):

For PostgreSQL this will result in events that are not easily readable:

SELECT payload FROM domainevententry;

| payload |
| 24153   |

The data type of the payload column of the domainevententry table is OID.

The PostgreSQL JDBC driver obviously knows how to deal with this. The real content is deTOASTed lazily. Using PL/pgSQL it is possible to store a value in a file. But this needs to be done value by value. But when you are debugging your application and want a quick look at the events of your application, this is not a fun route to take.

So we wanted to change the data type in our database to something more human readable. BYTEA for example. Able to store store large values in, yet still readable. As it turned out, a couple changes are needed to get it working.

It took me a while to get all the pieces I needed. Although the solution I present here works for us, perhaps this could not be the most elegant of even the best solution for everyone.
Read the rest of this entry »

Tags: , , ,

Posted in: Java

Kibana Histogram on Day of Week

11:25 on September 4th, 2017 by
No Comments

I keep track of my daily commutes to and from the office. One thing I want to know is how the different days of the week are affecting my travel duration. But when indexing all my commutes into Elasticsearch, I can not (out-of-the-box) create a histogram on the day of the week. My first visualization will look like this:

Read the rest of this entry »

Tags: , ,

Posted in: Elasticsearch

Smart energy consumption insights with Elasticsearch and Machine Learning

15:07 on August 21st, 2017 by
1 Comment

At home we have a Youless device which can be used to measure energy consumption. You have to mount it to your energy meter so it can monitor energy consumption. The device then provides energy consumption data via a RESTful api. We can use this api to index energy consumption data into Elasticsearch every minute and then gather energy consumption insights by using Kibana and X-Pack Machine Learning.

The goal of this blog is to give a practical guide how to set up and understand X-Pack Machine Learning, so you can use it in your own projects! After completing this guide, you will have the following up and running:

  • A Complete data pre-processing and ingestion pipeline, based on:
    • Elasticsearch 5.4.0 with ingest node;
    • Httpbeat 3.0.0.
  • An energy consumption dashboard with visualizations, based on:
    • Kibana 5.4.0.
  • Smart energy consumption insights with anomaly detection, based on:
    • Elasticsearch X-Pack Machine Learning.

The following diagram gives an architectural overview of how all components are related to each other:

Read the rest of this entry »

Posted in: Docker | Elasticsearch | Machine Learning

Heterogeneous microservices

13:52 on July 13th, 2017 by
1 Comment

Heterogeneous microservices

Microservices architecture is increasingly popular nowadays. One of the promises is flexibility and easier working in larger organizations by reducing the amount of communication and coordination between teams. The thinking is, teams have their own service(s) and don’t depend on other teams, meaning they can work independently, therebty reducing coordination efforts.

Especially with multiple teams and multiple services per team, this can mean there are quite a few services with quite different usage. Different teams can have different technology preferences, for example because they are more familiar with the one or the other. Similar different usage can mean quite different requirements, which might be easier to fulfill with the one or the other technology.

The question i’m going to discuss in this blog post, how free or constrained should technology choices be in such an environment?

Read the rest of this entry »

Posted in: Custom Development

Interview with Sam Newman, author of Building Microservices

13:15 on July 6th, 2017 by
1 Comment

After living in Australia for the last five years, the Londoner, and author of the well-received Building Microservices, has returned home to focus on his business as an independent consultant. We caught up via Skype to discuss his upcoming visit to Amsterdam and the tech trends that he is keeping his eye on.

Reading time: Less than 5 minutes

Read the rest of this entry »

Tags: , , , , , , , , , , ,

Posted in: Knowledge | Newsletter | Training

« Older Entries