The Next Frontier: Learning Microservices in the Classroom

As a Customer Success engineer here at Iron.io, I’ve been fortunate enough to see people using Iron.io in ways I never thought about. It’s actually one of my favorite parts of my job.

Recently, I was chatting with a customer who mentioned his students were using Iron.io in their final project. This peeked my interest, so I interviewed Soumya Ray, an associate professor at National Tsing Hua University in Taiwan, about his experience. Professor Ray’s  Service Oriented Architecture class is an 18 week course that takes students from idea creation to final product. And, as a cherry on top, the class has students create the building blocks of their own startup with zero dollars spent.

One of the main goals of the class is to enable students walk into any job and easily adapt to not just the technology used, but the company culture as well. It doesn’t matter whether that’s at a startup using bleeding edge technology or a more established company using the tried and true methods, after Professor Ray’s class, students will have the right experience for their new jobs.  

For example, because the class project starts with a blank page, it forces students to take things like scalability into account early on, rather than getting stuck with a stack that can only support 100 users. To help bring this point home, students actually visit startups to learn about easy mistakes to avoid and best practices to implement from the beginning.

Each week of the course, the students are introduced to a new concept, then work that lesson into their project. The topics may be database selection and implementation, continuous development, workers, queries etc. This is great but students tend to end up with a highly resource intensive, monolithic application. Thankfully, in Professor Ray’s project plans, IronWorker comes in at week 14 to help lessen the load.

By breaking the towering project down to smaller parts, the students are taught how to apply microservices in real world applications. Take something like scraping a website. It needs to be done, but really, there is a reason to ever require any interaction to do this? Why not send it to the background with a scheduled worker? Then, once you have the data you need, use another worker to do the data transform you need.

One of the examples of workers I was quite fond of was done by the group Hola. The worker scrapes other clothing stores to find the appropriate clothing it needs (while maintaining strict adherence to the robots.txt file), pretty straightforward use of a worker. But, rather than simply storing the data in AWS, they did some minor parsing and sent an email with the findings to potential shoppers who had signed up on their site. As with any project, I’m sure time constraints stopped some students from adding everything they wanted. Having said that, take a look at the Hola group’s impressive work:https://github.com/hola2soa/worker

This usually has mobile developers thinking, why not just use multithreading? On the surface level, it seems like they would both achieve the same thing, right? There’s many differences (fault tolerance anyone?), but the biggest difference is which machine is doing the work? Using multithreads is great, but the workload still falls on your shoulders. If you distribute the system, you also distribute the work. It’s a lesson many students have learned the hard way. To look into how other students accomplished this goal (or even ask them!) I highly recommend taking a look at their Facebook page- https://www.facebook.com/groups/ISS.SOAD

If you live near the National Tsing Hua University, I’d really recommend taking a look at Professor Ray’s class. It’s a great introduction to microservices in the world of Service Oriented Architecture, and a lot more.

If you’re using Iron.io for something neat and want to tell me about please do! Reach out to me via Twitter @jpksf