
Using API Simulation to Build Microservices Alongside a Java Monolith - tjcunliffe
http://www.specto.io/blog/using-api-simulation-to-build-microservices.html
======
agentgt
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).

~~~
deforciant
Hi. Hoverfly author here. I agree, messaging is vital in micro-services
environment. We chose HTTP(s) as the first protocol to "virtualize" to help us
better understand what additional functionality is needed (like hoverfly
middleware).

The problem with 0MQ/RabbitMQ is that it's not that
straightforward/transparent as in HTTP proxy. Initial thoughts to capture
messages would be to use something like this [http://api.zeromq.org/3-2:zmq-
proxy](http://api.zeromq.org/3-2:zmq-proxy) as a forwarder.

~~~
jdavenport
I've added an issue in our github repo to capture this and further discussion.

[https://github.com/SpectoLabs/hoverfly/issues/112](https://github.com/SpectoLabs/hoverfly/issues/112)

------
sbov
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.

------
dpeterson
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
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-
develo...](https://opencredo.com/javaone-building-a-microservice-development-
ecosystem-video/)

[https://opencredo.com/the-seven-deadly-sins-of-
microservices...](https://opencredo.com/the-seven-deadly-sins-of-
microservices-redux/)

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
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
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

