Picking the Wrong Tool for the Job
Picking the Wrong Tool for the Job
There are a lot of great developer tools out there, but they're not all right for your project. One developer explains who he learned this the hard way.
Join the DZone community and get the full member experience.Join For Free
Building real-time chat? Enroll in a Free Course on Mobile Chat Development.
It is very common that when something new is out, we all want to play with it, implement it in our daily work, and developing with the latest technology.
This sad story happened to me.
Back in the Winform days of Microsoft software development, we use to have the technology COM and DCOM to create application servers as part of the Enterprise Software architecture. That was the standard architecture and it had its share of problems (like not having one fixed network port but multiple random ones, and installing and uninstalling COM libraries was a nightmare).
Then .NET Framework appeared with ASP.NET and their WebForms. Webforms were intended to simulate Winforms so the Visual Basic community, which was big at that time, had no problems at all with embracing and migrating to the technology and at that point of time it worked very well. But we still do COM and DCOM for applications servers. The way .NET responded to this need was with a technology called “Remoting” but it was very proprietary and non-standard so we didn’t adopt it.
Then .NET 2.0 they introduced, Webservices, was a completely new way to implement an application server, it was web-based, standard port, and an XML standard was defined so it could be cross-platform and, like everybody else, we drank that kool-aid.
So, immediately after a new project was available we were hands on to implement web services. We created a web application for call center agents with 100+ users, which requires a lot of resources. We created two projects, one for the application server with the web services in place and the other for the web application with webforms for the users' work. We were careful on the web service project to implement layers so the business and data layers were separated from the web service files that expose the endpoints.
We felt that we were in a higher league, programming like professionals and doing first world development. The development was a breeze, everything was working perfectly. But then the project went to production.
In the old technologies we used to have almost a 1000 users working without any problem on one application. At that time, the high end servers had at most 2 GB RAM and no more than 10GB of hard drive space with two CPUs (no multicore) under the 1.5 GHz.
But now that we had new servers, with higher resources (4 GB RAM and 4 CPUs) the architecture approach was very slow, inefficient, and demanding on resources. We couldn’t reach the 100 users working properly. So we needed to start analyzing what was going on, what went wrong, and what was the difference.
It turned out that everything that we did on the webforms project was right, we didn’t have any problems at all there. But the web service project was a resources eater. The problem was that by creating the application server web interface base it needed too many resources to do all the communication. We find that if we put together the total amount of web request calls to the server, let’s say 1000 calls, the web service needed more than 550 to properly work. The object serialization and deserialization, the webinterface, the network transport factor, and having the webforms project to consume the web service shot us in the foot. XML uses a lot more payloads to communicate from the webserver to the application server on all possible fronts (CPU, Network, RAM, IO).
So we just embraced the new technology without making the right calculations as to what it involved or the right approach; we didn’t ask the right questions. That is the thing with the lack of experience, we had to learn by failing. We were overconfident, just like any new rookie (just in case you want to know, at that time web services were great for servers to communicate when they were at different locations or when servers with different platform need to communicate like .NET and Java applications).
I personally learned we need to be a lot more cautious when we intend to implement new technology since the vendors or the advocates will always say wonders about their product (nobody thinks their children are ugly) but the ugly stuff it is always hidden. This same experience with new technologies has happened to me a couple more times.
Fortunately, on the project that I've mentioned, the layered design implemented on the web service project saved the day by allowing us to create a library (DLL) with all the business and data logic and we got rid of the web service. We could do all that in just one day even though it was a big project. It worked immediately, the users now were able to work without any problem, the servers' resources consumption was low, we didn’t peak the 50% mark, and the application was fast.
Published at DZone with permission of Alfredo Pinto . See the original article here.
Opinions expressed by DZone contributors are their own.