SimpleAPM

The idea for SimpleAPM first came about in 2009 when a customer needed an APM solution that supported a non-web application. The only option at the time was a solution that cost more than $100,000.00, which was cost prohibitive for them. After several years of looking for alternatives to appear in the market, I decided to try and build a solution to support this customer so they could receive the benefits of proactive production monitoring. They funded the first version as a services engagement and committed to being a reference customer if things went well.

The Vision

The hope was to deliver something that could be developed for many companies with the same need – an APM solution with only the most useful features for the small to midsize market. It would include both the Digital Experience (customer centric view) in addition to the low level metrics, but it would be presented with visualizations that had non-technical people in mind. Easy to set up and monitor for issues, and (hopefully) find out issues earlier than through the support center. My understanding of performance engineering and testing made me a pretty good candidate to try and distill APM down for the non-technical, and I really enjoyed the prospect of creating something that would be so beneficial for companies that struggle to make sense of all the graphs and charts of a typical APM solution.

The first prototype was developed in 2016 using a 3rd party scripting IDE. This was to create application timings for end user experience. The timings were stored in a simple comma delimited text file and viewed in MS Excel. In the second version, the spreadsheet was moved to a database. The database schema was still extremely simple, and the main goal was to create a web based application that displayed graphs. Eventually it became an Apache Web Server, PHP code, and a MySQL database to store the end user timings. A free charting library and Javascript were used to render graphs. This worked as a bare bones prototype, but it was little more than a utility. As more data was created, it became slow and clunky.

Building SimpleAPM Is Hard

A developer was hired to create a full featured prototype using what I had built as an example. After six months of effort, THAT version was also slow, clunky, and not scalable out of the gate. The code was not usable and was dismissed completely. A third developer was hired to start from scratch. A working version of the product was created in two weeks! I was so excited. It was based on Python/Django with a local PostGreSQL database, and it supported MySQL and MS SQL Server as well. Although it was well received at the client, it still wasn’t scalable, or sustainable in the Enterprise. It still lacked major features for an APM solution. Unfortunately, the developer could not continue to develop the project further and I had to find someone else to work with. That version was implemented at the customer and worked as expected, even if the features were limited or incomplete. It it still running as this article is published.

Over the course of two years and many developers later, I had learned a lot…about failure to deliver! Being a product owner is so much different than running a consulting services company. For those of you who are new followers of me, I was previously the CEO of Northway Solutions Group and Loadtester Incorporated which provided performance engineering services. For almost a decade I ran a multi million dollar services company with up to 10 employees and 13 subcontractors. I am no stranger to business. I have sold a lot of software and tested many applications, but this was my first experience building software from scratch.

Over time, the product began to take shape. The product went through another architectural shift. Infrastructure decisions were made based on understanding the needs of the end clients. My customers were using commercial Enterprise software. Standard features for Enterprise software include scalability, security, and regulatory compliance. I needed to move from a utility mindset, to a SaaS mindset to make deployment easy. A whole new product emerged with an on-premise agent running doing a bunch of stuff, with a Dashboard offered as a multi-tenant SaaS offering. So at this point, I am becoming what I was trying to avoid by creating this complicated, more expensive solution and now I am going to be competing against Dynatrace, AppDynamics, and Datadog! The irony gets thick. It was never my intention to end up in this place.

As part of the evolution of the product, additional features turned into multiple products. SimpleRUM for real user monitoring, SimpleScriptless for a scriptless automation front end for Selenium, and other products became part of the offering. Integrations with other products began to happen. Visualizing LoadRunner VUGen, Neotys Neoload, and JMeter timings as the APM synthetic user without modifying any of the code or reengineering anything was particularly cool. However, it became larger than a single Founder.

Reality Kicks In

Now three years into building this thing we call SimpleAPM, with more than four completely different development companies all pretty much starting from scratch. Hundreds of thousands of dollars were put into this from my own pocket. I was at the point financially where I had no choice but to wander into the land of angel investors or venture capitalists. I met with several of them (both big and small investors). The one thing I always heard was, “This is a great idea. Making APM and Digital Experience simple and getting it into the hands of smaller to mid-sized businesses makes perfect sense…” It was always followed by, “…but this isn’t something we want to do.”

It turns out that if you aren’t going to go after the big boys (i.e. the Fortune 500) and hit a home run with million dollar contracts everyday, investors just aren’t that interested. It makes sense. They need a big return and that takes big money from big investors. In my experience in funding, the prospect of doing something just because it seems like the right thing isn’t as exciting to others as it is to me. Even so, I was still willing to go forward and figure out how to do it myself.

Dude, It’s Just a Graph

While the developer continued to work away sprint after sprint towards a release that we could demo to customers, I had to make sure I had all of the non-product items covered. This included product documentation, the web site, the trademarks, the legal documentation, tax issues – the stuff that most Founders don’t worry about until they have the product selling and have that “oh crap” moment. Having run a business before, these were easy but tedious. These were important items, but one-off things that I could knock out, and then focus on the product launch.

We were getting close. SimpleAPM was about 90% complete. Much of the internal plumbing was set up, and all I needed were the visualizations (i.e. the graphs). I had waited so long for the graphs, I had a running joke with the developers. “Dude, it’s just a graph…” I even had t-shirts made and sent it to the developer. It seems to me the hardest thing I ever asked of a developer was to give me a great looking graph.

Dude Its just a graph

Dude Its just a graph

And… Just Like That

During the time of finishing the legal paperwork, my new law firm recommended a clarification to an existing contract. To keep a long story short, all parties involved in that contract were unable to agree to a resolution and were unwilling to compromise. Like hitting a brick wall very hard – SimpleAPM stopped. Yes. Just like that. My original contracts were not created or reviewed by someone who specializes in SaaS solutions. When I did get that a law firm familiar with more of the technical landmines, it was too late. If you get nothing else from this, take your contracts with any companies or individuals extremely seriously. BTW – if you need a GREAT law firm who understands technology companies, I cannot recommend Pepper Hamilton LLP enough.

I visited with several more companies. This included angel investors and other developers, in hopes someone might be interested in taking it over and running with the original vision. No one wanted to do it without me as the key player. I understand why this is. I’m the dancing monkey that makes it exciting. The risk and time I was willing to put into this has reached the end, and I’m ready to call it a day on that vision. It’s been almost a year of slowly dismantling it, and with this blog I am closing the door on it and walking away. The hardest thing I had to do was go back to the original customer and look them in the eye and tell them that for the first time in my career, I could not provide the solution they asked for. After spending years (and 10X the money) they had originally invested in the prototype, I was unable to deliver.

I thought about a lot of options: Open Source, find specific companies and implement it as a service, or just giving it to someone. All of that is still on the table, but more than likely I’m just going to walk away and start doing things in my spare time I enjoy that don’t involve sitting behind the computer looking at graphs. I feel the call of the outside world more these days. The fish are biting and BBQ is on the grill. Spending more time with family seems like a much better use of my life hours now.

Lessons Learned

In my life, I NEVER LOSE. I am either winning or LEARNING. From this experience, I learned a lot more about software development than just the view from the performance and quality perspective. I learned the importance of contracts. I learned about venture (vulture) capitalism. I learned that it doesn’t matter if you have a great idea or even if you have the best product, you still may not win the hearts, minds, or dollars of customers. I learned how to do a few cool technical things that I did not know before and I can use that in my consulting business.

I have no bitterness or animosity towards anyone, even though it did not turn out as I wanted. I’ve gone back to my friends to whom I have asked many favors of during the course of trying to bring this product to market and told them how much I appreciated their help. I’ve assured them they should not expect that to be a frequent thing with me. The days of my “big ideas” where I need everyone to jump in with me and dogpile a problem are over.

The risk of failure is always there. The reward can be great, but one has to accept the impact of the risk, not just the concept of the risk. I will never regret what I did trying to build SimpleAPM. I would have had a regret having never tried.

 

SImpleAPM_Logo

About the Author

Scott Moore

Scott Moore specializes in application performance engineering and testing. This includes education, hands-on implementation, and application performance monitoring.