Being a Product Manager for a Polyglot platform

7 min read

I have to say it: to be in charge of the development, deployment, marketing, business development, customer success for a Polyglot platform is a constant challenge but very rewarding whe you have a happy client telling me:

“Marcos, you are doing a terrific job”, and I always answer: “You don´t have to thank me, you have thank to my team, because they are the rockstars, I just remove the obstacles and encourage them to keep doing an amazing job.”

So, I will give you some tips how to improve yourself for this kind of platforms.

First, I will tell you what I consider a Polyglot platform:

A Polyglot architecture is a platform where there are lot of different services and frameworks working together to bring the best performance for your clients

I know, this is a very simple definition, but I want to keep it in that way: simple, and this is my first advice for you: “Keep things simple”

Now, I wil give a description of the platform that I’m in charge. An image can worth a lot of words, so, I will give you the main architecture here:

Like you can see, it’s a Rails based app, with a lot of services behind. Some of the services are:

  • Ruby on Rails 2.3.14 with Ruby 1.9.3 (I will talk later how we migrated to Ruby 1.9.3)
  • Nginx HTTP Server + Unicorn + RVM for App nodes
  • HAProxy 1.5-dev19 for load balancing efforts (1.5-dev version comes with native SSL support)
  • Debian 6 (Squeeze) like base OS with a modified kernel for optimal performance (I will talk later about it)
  • Nginx + PHP 5.3.3 + SimpleSAML 1.10 + PHP-FPM for Single-Sign-One authentication service
  • PostgreSQL 9.2.4 like the main DB, for the DWH and the Operational Data Store (Awesome !!!)
  • Pentaho Data Integration (Kettle) for ETL services
  • Pentaho BI Server for Reporting modeling and visualization + Apache Tomcat (We are testing to deploy in JBoss)
  • Vmware ESX 5.1 like the main virtualization platform (Awesome !!!)

Now the tips

Trust in your team and embrace their improvement like pros every moment

I have the pleasure to manage a great combination of professionals, and they always ask me what to do for the next week. That’s the way that I learned they work better: instead to be above them, every second, and I saw that giving them a task and let them to think and work hard, they are more productive, and when they find a problem, we discuss how to solve it like a team. It doesn’t matter if they are a Software Developer, or an ETL developer, or a System Engineer; the best ideas can come from everywhere; so I encourage them to work like a team always and think in the “Big Picture” in every moment.

Get deeper in the technologies that you use

If it’s hard to build a product from conception to production; it’s even harder to take the management of an exiting product. Like my grandmother says in good cuban: “Te han dado una papa caliente !!!”, which in English can be translated like: “You have a very hot potatoe in your hands”. When I arrived here, there were a lot of problems with the platform: servers down every 5 minutes, the application with a lot of nasty bugs, all HTTP servers without any optimization, a very old Debian 4 installation like the main OS, lack of documentation for every node (some that I call Pandora’s boxes, because you don’t know what it’s inside), anyway; a lot of problems and challenges to solve. My background is in System Engineering and Database Management before to become in a Product Manager, and I had developed several RoR apps before, so, I began to use my experience with the framework and I began to ask to great RoR experts how to improve it.

So, I began with my team to make some key changes in the main architecture since its base: the OS layer. I did a little research and I saw that in Debian’s backports repositories, there was the new 3.x kernel version, and I built a custom kernel version for the platform without drivers, unnecessary modules, only with support for the hardware and virtualization platform that I wanted to have in the platform, and the system began to perform better with time. All advice, I saw them here and here.

Then, I saw that the platform was using Ruby 1.8.7, a very old version of the language and with a lot of bugs and tradeoff; so, I searched with my Lead Developer about the pros and cons to update the app to be compatible with Ruby 1.9.x, and we saw that with a week of hard work, we could embrace this new version, and then tune the Gargabe collector in Ruby with some great patches included in this version from REE (Ruby Enterprise Edition). So, we started to make the transition and we are very happy with the performance of the app right now. If you are using Ruby 1.8.7, don’t wait more and upgrade your Ruby first and then your Rails version, and in the process, don’t forget to use RVM and Bundle; both are two of the best things that I’ve worked with. Some resources how to do this migration:

The other thing that I saw that PostgreSQL was in an old version (8.3), and I’m long and proud PostgreSQL user, so I know the benefits behind the last version of the system; so, we started to work to make the platform compatible with recent versions of PostgreSQL: first with 8.4 and then with 9.2; and then, we started to tune the OS layer and the database system to make it fly.

Learn to say NO gracefully

The important tip here is not the word NO itself, but you have to learn to communicate to you team why you are saying no; not like a jack ass, but with strong reasons to convince them. This is one of the hardest things that I learned with experience; and now, for a decision of this kind, I let to the member of my team to expose their points and we discuss everything, and I always to try that they find the answer by themselves, always with a Big Picture in mind, so, I don’t say not: they say NO to themselves if we all saw that a particular feature or change is not a priority right now, or it’s feasible in time and effort. Remember: one of the main responsibilities of a Product Manager is to explain to your team and to your customers all WHAT and WHY of your platform, and the answers that carry out a NO, you have to explain WHY is NO; learn to do it.

Develop, Measure, Monitor cycle

One of the best advices that I’ve ever heard came from Guillaume Luccisano, VP of Engineering at Socialcam:

Develop a feature, measure its performance, and monitor everything again; and repeat the cycle. It doesn’t matter if you use NewRelic, Nagios or Ganglia, monitor everything

You can find this one and many more good tips on his Efficiency at Scale talk at AWS:reInvent 2012, explaining how they scaled Socialcam to more than 100 millions of users:
 [slideshare id=15493252&doc=stp201efficiencyatscale-121204195808-phpapp02] 
 If you like this kind of problems, they are hiring a Rails Scaling Panda for the Socialcam’s team.

Make to Speed your best allied and keep always your customers happy

This tip comes together with the above point. Speed is your best allied to keep your customers happy, because you have two seconds, believe just two seconds to convince to your client that yout platform is in a Bullet Train or in a bulldozer. So, in the case of RoR apps, try today to update your system to use the last Ruby releases and the last version of the framework. See this post at EngineYard about this topic, or this guide at Heroku.

Embrace best practices but test them by yourself

There are a lot of best practices for RoR development, and this is good, I know, but don’t trust in every word on Internet: test them by yourself. I learned this from a painful experience, because the first choice to deploy the app was Thin, and everything was going very well until the last December which everthing went down, because the quantity of requests for Thin workers was huge, and it wasn’t attending very well this massive number of requests. In that point was when I was promoted to Product Manager and the management team gave me this platform. And I began to see the alternatives to Thin, and I found the amazing post at GitHub about Unicorn, and I’ve never looked back.

Become to every member to a Data-Driven person

If you are reading this blog, is because you are a Data-Driven person too, you trust in your Data and your Analytics, so you have to encourage to your peers to trust in Data. I think that everyone should listen more to the Analytics department, but not just the Analytics team; everyone can see the whole picture and think in great ideas how to measure information, how to capture events that involves Data, how to manage all this; anyway, they have to use all available data to make decisions quickly and effectively.

Improve your Soft skills in every opportunity to do it

I talked a lot about Soft skills here, so, you just have to read that article.

Conclusions

Well, my dear friends: to be a PM for a Polyglot platform is hard but at the same time it’s a challenge and it’s very rewarding, because you see a happy customer talking very good things of the platform, it’s very rewarding, so, take the opportunity, and make an impact in your work like PM. Best wishes and thanks for reading.

Marcos Ortiz

Marcos Ortiz

More posts
Previous Post
Next Post