Considering the time, cost and effort of building their own integrated development platform, many organizations — especially small to medium-sized organizations — turn to PaaS over an IaaS approach.

Platform as a service will provide a microservices development team with everything it needs to get an application rolling, including a prebuilt, fully provisioned development platform that developers can share, along with a set of preconfigured tools that integrate with that platform.

However, an organization may outgrow PaaS, especially if it begins to delve deeper into microservices development and the scaling out of the architecture. This doesn’t mean PaaS is not a good starting point, but it does mean that organizations may have to consider adopting the infrastructure as a service (IaaS) approach as an addition to, if not a replacement for, their PaaS foundation.

“The size of the organization is probably the most important factor,” Chris Tozzi, a DevOps analyst for Fixate IO, explained. “If you’re a startup with a small IT team [and] you don’t have staff with time available to set up a custom delivery chain, you probably would get better value from a PaaS. In that case, PaaS is often the easiest path to continuous delivery for small to midsized shops.”

On the other hand, it is possible for a microservices development team to need more than PaaS, according to Randy Shoup, VP of engineering at Stitch Fix. Shoup, who has overseen the expansion of Stich Fix’smicroservices architecture, describes PaaS as “a wonderful cage” that helps until developers want more freedom, especially as the scope of applications grows.

“The largest [organizations] will always exceed what the platform can do,” he said. “As your developers become more proficient in working with microservices, they may enjoy working in their own in-house development environment and the freedom to use whatever tools they want.”

He added that an organization may also simply want more control over microservices-based applications and the infrastructure that lies beneath them.

Another reason organizations may outgrow PaaS is that microservices developers and application managers begin to demand increased visibility into the underlying infrastructure of an application in order to fix problems or make quick changes. For instance, many PaaS options do not allow developers to see how requests are routed between applications and services, which can be important for some developers to know. With PaaS, developers will be dependent on a third-party IaaS provider to fix any underlying infrastructure issues. Sometimes, this approach does not reveal exactly what occurred.

“When it is slow for somebody to make a call to our billing service, I want to be able to get in there, diagnose it and fix it,” Shoup explained. “With all the PaaS platforms that I’m familiar with, I can’t do that.”

However, Shoup reiterated that, even for well-established organizations, PaaS is an effective launching point for revamping their software architecture and creating a functional, standardized development environment.

The post How long will PaaS work for microservices development? appeared first on Artificial Intelligence.

The last time I wrote a book, I was pretty sure I would not write a new one — or at least not about Python. Writing a book is a lot of work.

The hard part is mostly about not quitting. After a day of work and taking care of the kids, sitting down again at my desk for a couple of hours was just hard, in particular since I do other stuff like running. I stole time from my wife.

The topic, “microservices” was also not easy to come around. When I was first approached by Packt to write it, I said no because I could not see any value of writing yet another book on that trendy (if not buzzwordy) topic.

But the project grew on me. I realized that in the past seven years, I have been working on services at Mozilla, we did move from a monolithic model to a microservices model. It happened because we moved most of our services to a cloud vendor, and when you do this, your application consumes a lot of services, and you end up splitting your applications into smaller pieces.

While picking Python 3 was a given, I hesitated a lot about writing the book using an asynchronous framework. I ended up sticking with a synchronous framework (Flask). Synchronous programming still seems to be mainstream in Python land. If we do a 2nd edition in a couple of years, I would probably use aiohttp 🙂

The other challenge is English. It is not my native language, and while I used Grammarly and I was helped a lot by Packt (they improved their editing process a lot since my first book there) it’s probably something you will notice if you read it.

Technically speaking, I think I have done a good job at explaining how I think microservices should be developed. It should be useful for people that are wondering how to build their applications. Although I wished I had more time to finish polishing some of the code that goes with the book, thankfully that’s on GitHub, so I still have a bit of time to finish that.

Kudos to Wil Khane-Green, my technical reviewer, who did a fantastic work. The book content is much better, thanks to him.

The post Python Microservices Development appeared first on Artificial Intelligence.