Why Software Intelligence?
As an entrepreneur, when you get a quote for software, do you know what you’re getting? Does the software company know what stage you are at, and what you are expecting? Do you know what you’re expecting?
When it comes to building software, the term “100 ways to skin a cat” is more relevant than ever. You could spend as little as $15,000 or as much as $1,000,000. This article will go over the different kinds of structure software can take, the benefit of each and why software can get really expensive.
To demonstrate, we’ll use an example application for that is a website for renting vehicles. Users can sign up, enter their location, choose their vehicle, and enter their payment information to checkout.
The Monolith Structure
A monolith application structure is one, eventually large, application. I say “eventually large” because they all start out small and simple, but as features are added, and the market changes, the monolith becomes a monster.
For our car rental application, there would be one application with these parts:
- User Interface
- Code for saving and updating rentals, users, vehicles…
- Database for saving all the information
The beauty of the monolith structure is that it can be created and delivered quickly, getting you up and running with the features you need. A developer can get a generic monolith application running for you in a matter of hours with the features that most websites or mobile applications have, like a database, user login, and a home page. The developer will then add your specific application needs, so you can start testing it with users within a few month or so, depending on the complexity of the application.
This is a good option if your product is new and you don’t want to invest significant time and money into it before testing it out on your market. You can get your application in front of your potential customers fast and test your revenue generating theories.
The monolith is relatively inexpensive. Prices can range from $15,000 to $80,000 for a monolith application. This is dependent on the complexity of the project, and the development companies expertise in your market.
While the monolith structure has it’s pluses, it quickly becomes difficult to scale. You can’t scale only the parts that need more resources, you need to scale the whole thing. This is why many successful applications fail early; they cannot handle the audience it generates.
Eventually, it becomes difficult for the development company to support the monolith application. Since there is only one application, adding too many features at once can be troublesome, so these applications are only managed by one or two developers. And when new features are released, the entire application (cause it’s one monolith) needs to be built up and published to your production server. This leads to errors and bugs.
Also, the code become stale. The software industry moves fast, and what was the best solution at the time your monolith application was written, may not be a recommended technology 12 months later. If a core part of the application looses support, (maybe is built on an old version of code), the whole thing needs to be updated at once, instead of a small part at a time.
Because updating the technology means updating the whole application, it typically doesn’t happen. The application gets stale and the engineer gets bored with it. If your engineers are on your payroll, this could lead to them looking elsewhere for work.
The Distributed Structure
The distributed structure means you have many small applications that talk to each other instead of one large application. This structure is best used when it is known that the application will have high usage, and the resources needed to build it will be returned. Typically, a distributed application is what a company makes after their monolith application needs to be rewritten because it grew out of control. It worked, and is making the company successful, but needs to be built correctly now that the revenue generating theories have been proven or debunked.
For the car rental application, there could be multiple small applications like this:
- User Interface
- User Interface Gateway Application
- Car Management Application
- Rental Management Application
- User Authentication Application
- Payment Processing Application
Each small (micro) application is self contained and has one focus. For example, the Rental Management application would have rental locations with a list of cars. The Car Management application would have a list of cars with each cars current location.
Micro applications don’t need to communicate directly with each other. They just send a message out saying that they are done doing something, and if another micro application is interested in that message, it will listen for it and do something. For example, if a car moved to a new location, the Rental Management application would remove the car from one location, and add it to another. When done, the Rental Management application would send out a message for all applications to hear stating that it “Car X moved from Location Y to Location Z”. The Car Management application would hear this message, and act on it by updating the car with it’s new location.
The distributed application can hit prices from $150,000 to $1,000,000. This is dependent on the size of the project.
There are many benefits to using the distributed application structure instead of one large monolith structure.
- Small applications are easier to change so your new features will be released faster.
- If one micro application starts getting used more, you can scale it individually from the rest of the system.
- With each micro application focused on one purpose, splitting up work among the team(s) will be smoother. Teams can grow and engineers won’t be stepping on each others toes.
- Engineers get to try new things as the applications are smaller and can be re-written easily as time goes on (this keeps engineers happy, no one likes to support an old monolith application, even if they wrote it.)
- Price tag: Because there are more applications, the cost of hosting and developing this application goes up significantly. This is why many companies start out using the monolith structure that can prove profitable to an investor, and with the investment, make the real application as a distributed structure.
- More Complex: These systems are easier to maintain compared to a large, out of control monolith. But they are complicated if the development team hasn’t created one before. If you used a family friend or neighborhood kid to create the monolith application, there is a chance the distributed application would be over his head. Distributed systems mean you are most likely going to use a cloud hosting provider like AWS (Amazon Web Services) or Microsoft’s Azure.
So which do I use?
When you are creating a new application for the world to see, you need to test it on your market. You don’t want to spend resources on something that doesn’t bring in revenue. Because of this, for new projects, I would suggest using the monolith structure. It’s quick and can validate your theories on how you will make money. If your theories are found to be incorrect, change the application until it starts being successful in your market. If you find that there is no hope for the application, then your investment is minimal.
Is it possible to start with a monolith and convert it over time? The answer is yes. But that might not always be the best. Sometimes, the initial monolith application is best to be thrown away and a distributed application is started with a fresh slate. What you don’t want to throw away is the knowledge the development company has about your business. While they were making all those changes to your application during the products growth, they were learning what is important to your business. If the same company is making your distributed application, their knowledge they learned about your business is what’s priceless, not the code they wrote.
When making your software, remember that there needs to be an administrative interface as well, this needs to be taken into account when developing your solution. Learn more about the administration of your website at http://www.53prime.com/2017/08/31/software-support-doesnt-matter/