8 ms·

Using API Simulation to Build Microservices Alongside a Java Monolith

71 points by tjcunliffe 11y ago

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
dpeterson 11y ago
I am in this situation right now. We are frozen in the planning stages of moving a Java monolith toward a micro-service architecture. This seems like a very straight forward understandable approach to help make that happen. I read the article and could easily understand what the tool is trying to do and how it can help.
- danielbryantuk 11y ago
  I'm the article author, and it's great to hear your feedback! I've published a couple of other articles that may help with the topic of microservices: https://opencredo.com/javaone-building-a-microservice-development-ecosystem-video/ https://opencredo.com/javaone-building-a-microservice-develo... https://opencredo.com/the-seven-deadly-sins-of-microservices-redux/ https://opencredo.com/the-seven-deadly-sins-of-microservices... I'm also looking for more suggestions of how people will want to use Hoverfly with Java projects, and so please do give me a shout via twitter @danielbryantuk if you have any ideas!
  - dpeterson 11y ago
    One sticking point; what if the monolith does not have an endpoint you can call with an http request? What if you have a client that consumes the back end with server rendered pages and no services are exposed with url endpoints? Do you first have to make the monolith's internal functionality accessible via http requests?
    - danielbryantuk 11y ago
      Adding 'seams' into the monolith (and exposing this typically via REST or AMQP) is the most effective way I have found. The alternative is to 'screen scrape' the data returned from calling the monolithic application via the interface exposed now. For example, calling a website page, parsing the HTML data returned, and extracting what you require. However, the code/algorithms you have to write are typically complicated, and the resultant code often fragile and highly-coupled
- jdavenport 11y ago
  This is John Davenport at SpectoLabs. We have used AspectJ to create new seams (in Daniel's terms) in Java monoliths that can then be intercepted via http. It all depends on what sort of bind you find yourself in. Having seen both the Hoverfly approach is far preferable, but one approach may be to use AspectJ, create the seam via http and then intercept using Hoverfly. YMMV.
agentgt 11y ago
The problem is that we don't use HTTP(S) for micro-services but rather ZeroMQ and/or RabbitMQ. Many async pub/sub platforms are much more complicated to test. I assume Hoverfly doesn't yet support other protocols but does it plan too? Or maybe its just that micro-service at this point must mean simply RESTful API over HTTP(S) (which is sad because I think its a subpar protocol for IPC particularly pub/sub). Given today's demand for streaming like apps I'm not sure I'll ever build a plain ole HTTP Request/Reply platform (which I guess is what most people equate to micro-service).
- tjcunliffe 11y ago
  A lot of people we have spoken to have asked for this, so support for messaging protocols is definitely on our roadmap. Whether it will be incorporated into Hoverfly, or provided as a separate tool hasn't yet been decided though.
- mogronalol 11y ago
  I'm curious as to the use case for this, so was wondering if you could please elaborate. When you use messaging the communication is asynchronous and therefore the applications are decoupled by nature. So when testing a service like this in isolation I would assume you just need to assert that it publishes / consumes messages correctly, not needing to worry about what happens with the services on the other side of the broker. I think I am missing something?
  - agentgt 11y ago
    Yes and no. Some incoherent thoughts below: For plain fire and forget you are correct that async pub/sub is decoupled and in fact while our monolithic app is monolithic it actually is fairly decoupled because of this (e.g. it often is the receiver of its own messages it published). However there are async request/reply scenarios. Basically a client requesting for a stream asynchronously (this is different than normal request/reply) or even plain request/reply over a messaging protocol (which is done often for better or worse). For our case it isn't so much that the monolithic app is poor architecture wise (in fact its sort of convenient to have a homogenous fleet of servers) its that the monolithic server makes prototyping a pain (ie some nodejs developer doesn't want to have to boot up the massive Java app). I think a mirror tool would be useful for this. I think Hoverfly like thing could be built as a RabbitMQ plugin or I guess you could publish messages to multiple exchanges has one way of recording/mirroring.
sbov 11y ago
We already do this in our monolith. All business operations are declared on interfaces, which is used to codegen a client & http request handler. Normal app code uses the codegen'd client, and we have a REST api which runs the codegen'd http request handler (and underlying business logic that we write by hand). This gives us certain kinds of flexibility that we use. That said, it's still a monolith. Even if we split each call onto a different server ultimately they will be relying on a shared database schema residing on the same, singular MySQL server.

71 points by tjcunliffe 11y ago

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

dpeterson 11y ago

I am in this situation right now. We are frozen in the planning stages of moving a Java monolith toward a micro-service architecture. This seems like a very straight forward understandable approach to help make that happen. I read the article and could easily understand what the tool is trying to do and how it can help.

danielbryantuk 11y ago
I'm the article author, and it's great to hear your feedback! I've published a couple of other articles that may help with the topic of microservices: https://opencredo.com/javaone-building-a-microservice-development-ecosystem-video/ https://opencredo.com/javaone-building-a-microservice-develo... https://opencredo.com/the-seven-deadly-sins-of-microservices-redux/ https://opencredo.com/the-seven-deadly-sins-of-microservices... I'm also looking for more suggestions of how people will want to use Hoverfly with Java projects, and so please do give me a shout via twitter @danielbryantuk if you have any ideas!
- dpeterson 11y ago
  One sticking point; what if the monolith does not have an endpoint you can call with an http request? What if you have a client that consumes the back end with server rendered pages and no services are exposed with url endpoints? Do you first have to make the monolith's internal functionality accessible via http requests?
  - danielbryantuk 11y ago
    Adding 'seams' into the monolith (and exposing this typically via REST or AMQP) is the most effective way I have found. The alternative is to 'screen scrape' the data returned from calling the monolithic application via the interface exposed now. For example, calling a website page, parsing the HTML data returned, and extracting what you require. However, the code/algorithms you have to write are typically complicated, and the resultant code often fragile and highly-coupled
jdavenport 11y ago
This is John Davenport at SpectoLabs. We have used AspectJ to create new seams (in Daniel's terms) in Java monoliths that can then be intercepted via http. It all depends on what sort of bind you find yourself in. Having seen both the Hoverfly approach is far preferable, but one approach may be to use AspectJ, create the seam via http and then intercept using Hoverfly. YMMV.

agentgt 11y ago

The problem is that we don't use HTTP(S) for micro-services but rather ZeroMQ and/or RabbitMQ. Many async pub/sub platforms are much more complicated to test. I assume Hoverfly doesn't yet support other protocols but does it plan too? Or maybe its just that micro-service at this point must mean simply RESTful API over HTTP(S) (which is sad because I think its a subpar protocol for IPC particularly pub/sub). Given today's demand for streaming like apps I'm not sure I'll ever build a plain ole HTTP Request/Reply platform (which I guess is what most people equate to micro-service).

tjcunliffe 11y ago
A lot of people we have spoken to have asked for this, so support for messaging protocols is definitely on our roadmap. Whether it will be incorporated into Hoverfly, or provided as a separate tool hasn't yet been decided though.
mogronalol 11y ago
I'm curious as to the use case for this, so was wondering if you could please elaborate. When you use messaging the communication is asynchronous and therefore the applications are decoupled by nature. So when testing a service like this in isolation I would assume you just need to assert that it publishes / consumes messages correctly, not needing to worry about what happens with the services on the other side of the broker. I think I am missing something?
- agentgt 11y ago
  Yes and no. Some incoherent thoughts below: For plain fire and forget you are correct that async pub/sub is decoupled and in fact while our monolithic app is monolithic it actually is fairly decoupled because of this (e.g. it often is the receiver of its own messages it published). However there are async request/reply scenarios. Basically a client requesting for a stream asynchronously (this is different than normal request/reply) or even plain request/reply over a messaging protocol (which is done often for better or worse). For our case it isn't so much that the monolithic app is poor architecture wise (in fact its sort of convenient to have a homogenous fleet of servers) its that the monolithic server makes prototyping a pain (ie some nodejs developer doesn't want to have to boot up the massive Java app). I think a mirror tool would be useful for this. I think Hoverfly like thing could be built as a RabbitMQ plugin or I guess you could publish messages to multiple exchanges has one way of recording/mirroring.

sbov 11y ago

We already do this in our monolith. All business operations are declared on interfaces, which is used to codegen a client & http request handler. Normal app code uses the codegen'd client, and we have a REST api which runs the codegen'd http request handler (and underlying business logic that we write by hand). This gives us certain kinds of flexibility that we use. That said, it's still a monolith. Even if we split each call onto a different server ultimately they will be relying on a shared database schema residing on the same, singular MySQL server.