2

I'm the maintainer of an ASP.NET WebForms application and am contemplating a refresh of the application in order to eliminate dependency on some legacy libraries, add some features, fix some areas where application behavior does not adequately match up with real-world business practice, etc. So, I'm looking into current best practices and trying to figure out what makes sense for a relatively small web application such as this.

I'd heard of (but not previously used) Docker, so I figured I should spend some time learning what that's all about. Thus, I came across various materials recommending microservices architecture and API gateways as the new thing that everybody's doing. Upon learning a bit more, I find myself wondering if this approach is overkill for an application of this size.

My question ultimately boils down to: In the context of a small, internally-facing web application, what criteria would you use to determine if the extra development overhead of a microservices architecture is justified by the architectural benefits?

For a size reference, the current monolithic WebForms application consists of:

  • ~30 database tables, including tables generated by the ASP.NET Membership & Roles frameworks
  • ~30 .aspx pages
  • has ~60 active users
Improve this question
7
  • I think this is fairly subjective. It depends on many factors other than size, and whether it's "worth it" is entirely up to you. Commented Nov 14, 2019 at 21:17
  • Docker has a different use case than microservices. Commented Nov 14, 2019 at 21:27
  • And to be fair, your application doesn't look like it's large enough to benefit from microservices. Microservices are the new golden hammer (where everything looks like a nail), but realistically I don't see the benefits unless you're large and/or geographically dispersed. Commented Nov 14, 2019 at 21:29
  • 1
    Fair enough. Frankly, I think you'd benefit more by gradually moving your application to ASP.NET MVC. You'd get a significant performance improvement, and your application would become modular enough where working with microservices would become a more viable option. Commented Nov 14, 2019 at 21:31
  • 1
    OK, so there are plenty of resources on the Internet that say why one might to choose a Microservices architecture, but I'm a big fan of balancing those advantages with the potential costs, so here is an article that sheds some light one what some of those costs are: blog.runscope.com/posts/5-reasons-not-to-use-microservices Commented Nov 14, 2019 at 21:45

1 Answer 1

Reset to default
7

As I see it, the size of the application doesn't really have much to do with the microservices pattern. After all, you can always choose to build a few large monoliths or to build a monolith out of lots of smaller libraries where it makes sense, or keep it in one large codebase using modules/namespaces/packages/whatever-your-language-offers.

The use cases for microservices are to reduce operational complexity and to increase architectural agility.

Operational complexity is when the core software isn't terribly complicated, but the day to day of it has severe challenges. Think of Twitter as an example. Your standard line of business application is probably solving a harder problem than Twitter is. After all, you could probably hammer out a quick microblogging application in a weekend. What differentiates Twitter is the servicing of billions which leads to very distinct challenges. Microservices help by allowing selective scaling. In conjunction of other patterns, like bulkheads and circuit breakers, it makes it easier to contain faults or errors in one portion of the system. There are other examples, but I hope this gives a good idea.

Architectural agility is important when you have a lot of teams working on the same system, especially when you don't necessarily have all of the what or the why worked out up front. The ability to segment the code base by artifact so that teams are less likely to step on one anothers' toes while working. Moreover, you gain the ability to combine multiple languages and frameworks in ways you really can't in a monolith.

Of course, these advantages come with a price (because all magic comes with a price) and that price is that there is extra complexity injected into the system. The question comes down to whether that complexity buys you enough in terms of operations and agility to be worthwhile. That is very specific to your use case. I imagine we will see a snap back in a few years to running monoliths on cloud infrastructures followed by a more nuanced balance between the two where products pick what makes sense and move up and down the microservice spectrum depending on their goals.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.