I have a monolithic application. It is MVC, PHP, all on one server. It does get copied to another server or replicated. There are also older web pages that connect to databases that aren't related to the MVC app at all, adding to the complexity.

I don't have a large team. I don't need big teams from various sections of a business to produce a microservice. But, I do have a lot of databases I have to query and bring back that information into a single web page, transparent to the user. Not just tables, whole databases.

On my application, the back-end, I have IIS, for example, and the application has various models that get the information from the databases. Over time, these models get bloated, or the controller does. Refactoring has to happen (this is my experience anyway.)

This system is older, and new things need to be added, lots of things. It is enough to justify a new web application.

In this new application, if I want to use JavaScript on the front-end that consumes a REST API, is the combination of thes REST APIs the same as "Microservices"?

Other than a possible mess, what kind of architecture am I explaining? I want to use REST because other than myself using the API, others can as well. I can simply return JSON to them (and my application).

EDIT: Here, http://www.martinfowler.com/articles/microservices.html, one of the statements Martin Fowler makes several times is, "With a monolith any changes require a full build and deployment of the entire application." What does this mean? If I build a web application and change a Title, I don't rebuild anything. I now that's simplistic, but say I have a model, I change my SQL to get a new column. I put a new bit of Javascript and HTML and I'm done. I am not saying that's good, just that it happens, and I'm not sure why what Martin Fowler says here affects me.

  • 2
    When he says the application must be rebuilt, he's talking about compiling and deploying it. With PHP there is no compiling, but you still have to deploy those files to your web server. Every deployment incurs risk of failure. That's what Fowler is talking about. – Greg Burghardt Dec 1 '16 at 20:57

You are asking the right questions. Using REST Services and JavaScript does not make a microservice.

Martin Fowler has an article that attempts to define the characteristics of what makes up a Microservice Architecture. This is definitely worth reading as it cleared up a lot things for me on this topic.

To summarize the article (for those TL;DR oriented):

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Microservices advantages over monolithic applications:

the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .

  • Why does Fowler say, "requires the entire monolith to be rebuilt and deployed." for a monolith. You don't have to do that for a small change, so I don't know what he means. – johnny Dec 1 '16 at 20:16

An API call can be RESTful, part of a micro service architecture (one or the other), neither or both. They are different terms that mean different things.

RESTful means conforming to REST principles. Resource based calls, rather than procedure based calls, for example.

Micro-services essentially break down large functionality into smaller, more manageable and re-usable pieces.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.