A workshop on cryptography I made at 42 with my friends from Stelau.
For a while, it looked like cloud computing, the Platform-as-a-Service (PaaS) model in particular, would be one of the many casualties of the Global Financial Crisis of 2008. However, more than a decade later, the PaaS model is stronger than ever. Not only has 2019 been off to a promising start but the researchers from Gartner are now predicting that the PaaS market will double by the end of 2022.
According to the latest information, there are currently close to 400 PaaS providers offering more than 550 different PaaS-based services. In addition, many companies are choosing to develop their own PaaS.
In this article, we will look at the current state of the PaaS market and consider the pros and cons of developing your own PaaS as opposed to opting for one of the public cloud-based solutions. But first, here’s a quick overview of the main cloud computing models and what each of them involves.
The Three Key Cloud Computing Models
When discussing cloud computing, we are usually talking about one of the following three models:
- Platform-as-a-Service (PaaS)
- Software-as-a-Service (SaaS)
- Infrastructure-as-a-Service (IaaS)
While PaaS isn’t the most common of the three models (that distinction goes to SaaS), it is by far the fastest-growing. With this method, providers give you an already developed and functional framework to create and manage your software without having to worry about any maintenance – that’s taken care of by your PaaS provider. Although you get to keep ownership of your software and may even get access to the tools to deploy and test your apps, you have no control over hardware or the operating system.
As already mentioned, SaaS is the most common of the three models, and as its name suggests, it is all software-based. Users access everything via their web browsers and don’t have to worry about hosting, perform regular updates, or download and install any software on their machine. With SaaS, you get a more cost-efficient solution that will relieve your IT team of time-consuming management duties. However, if the system experiences downtime, your IT team will have to wait for the provider to fix it.
Finally, there is IaaS, a model that involves the most responsibilities and management work for users. Under this model, the provider uses virtualization technologies to deliver the infrastructure with all the physical hardware installed and taken care of. Everything else is in the hands of the end user. While this gives users most control of their data, it also puts them in charge of handling their own runtime and operating system, as well as taking care of system security.
What to Expect from a PaaS Provider in 2019
Although different providers offer different perks and benefits, most of them offer the same core services. When looking for a PaaS provider in 2019, you should always look for the following services:
Full Database Management
If you’re looking for a PaaS solution, you expect your provider to take full care of the infrastructure, including database and security management. Your provider should be able to ensure data privacy and handle all the necessary compliances.
Support for Multiple Programming Languages
A good PaaS provider won’t limit you to just one or two most popular programming languages. Instead, they’ll give you the freedom to develop your apps in your preferred language, whatever it may be. There are many platforms out there that support languages from Python and Ruby on Rails to Java and Scala.
As a software developer, you want your PaaS provider to give you access to all the tools you need to produce high-quality apps and software. This includes testing, debugging, and employment tools. What’s more, good PaaS providers also give you full control of the development process, allow you to test and implement changes in record time, and independently scale every single component of your app.
Focus on Mobile
When looking for a good PaaS solution, you also shouldn’t overlook the mobile component. Namely, your provider of choice should give you access to a range of options to design, develop, and deliver mobile apps.
Of course, these are only some of the key services you can – and should – expect from any PaaS provider worth their salt in 2019. In addition, many platforms also allow you to build apps using the so-called drag-and-drop method, thus ensuring that even business users with no programming skills can develop software for their needs. Plus, most providers give you access to their own marketplaces where you can find apps and add-ons that allow for easier and more effective management of your PaaS.
Should You Build Your Own PaaS?
Despite the sheer number of publicly available PaaS solutions, some businesses opt to build their own PaaS. Most businesses choose to do this to gain full control of their system and eliminate the potential security concerns that exist with some public PaaS providers. But is this really that good an idea in 2019?
That really depends on how much time, resources, and money you are willing to invest in building and maintaining your PaaS. You see, a PaaS involves five major components – infrastructure (network, storage, firewalls, etc.), operations (e.g. inventory and finance reporting), continuous delivery (blue/green deployment, artifact repository, etc.), data and middleware (HTTP, proxies, databases, etc.), and perhaps most importantly security (data protection, threat detection, certificate management, etc.).
If you’re willing to take on this task and set up a team that will help build, launch, and continuously maintain your own PaaS, you can give it a try. Keep in mind, however, that it is a major commitment. If anything goes wrong – and it sometimes will – you stand to lose a lot. As such, it is important to understand what you’re getting yourself into before making any decisions that could hurt your business.
The Decision Is Yours to Make
Don’t be discouraged by what you’ve just read. As with everything in business, the decision is yours to make. If you decide to create your own platform and do it successfully, you can expect better security and more control of your system overall. And if you’re still unsure about making such a big step, with almost 400 PaaS providers and counting offering top-quality services and constantly upgrading their catalog, you are sure to find at least one solution that is perfect for your company.
Few days ago, I organised and hosted a Hackathon at Berty.
Two days of code and startup-design with friends, a new network, new opportunities, new ideas, and a lot of fun.
- Berty (me)
- Osmose (Zooma & Zaraki)
- La suite du monde (Adrien)
- Busy (Ekitcho)
- Independants (Loup, Norman)
- Projects presentations
- Discuss about “how to work together”
- Focus on code
What we’ve done
- Meet people
- New friends
- New colleagues ? :)
- Refactor if the web radio of Osmose / La suite du monde
- Using with Liquidsoap, Docker, Icecast, Golang
- Plan to plug it with Discord / Telegram to interact with users
- Automate “La suite du monde” processes (onboarding, federation, delegation, scouting, etc…)
- With Airtable, Zapier, custom scripts
- Leboncoin / Seloger scraping with Scrapy (Python)
- Discussions about Blockchain
- General discussions to raise the knowledge of everyone
- Main net / Test net / Token Economy
- Features planning
- Blockchain-based project architectures
- DPOS strategy for Berty
- La suite du monde strategy
- Osmose strategy
- Busy strategy
- Blockchains comparisons
- Architecture of an event ticketing & wallet system based on the blockchain
- Blobby Volley, Jackbox
- Nom nom nom
- IRL Cryptography/Steganography game (fake telepathy)
10 minutes to get a job, by 42
42 recently launched a series of conferences named “10 Minutes to get a job”, the title is a little bit counter-intuitive, because, the 10 minutes hard-limit is for the organization presenting its activities; the students have all the time they need after the presentations, with some fresh foods and drinks.
This series of conferences is very successful, a lot of students looking for a job (or just curious) are coming in the room for the presentation, and a lot more are coming for the buffet after (not sure about the motivation for these ones). 😄
Berty’s first public presentation
It was something totally new for the Berty team, the first time we talk about the project publicly, and as the project is still under development, we selected pieces of information that can be shared and that are is relevant and “sexy” for the students.
With the constraints of “10 minutes”, we made the choice of using preparing a mind-map with facts, no phrases, no images, and then I made the presentation by going word by word, and by expanding each mind-map folder’s.
It’s a little bit more complicated than a more standard conference, as I have to concurrently speak at the microphone, read the slide, move the zoomed map, expand folders, and everything in less than 10 minutes. Luckily, I made it in 9:55s and the organizer allowed one question from the audience.
The cool thing about this mind-map based conference is that at the end, there is only one slide, containing all the pieces of information and that everyone physically (and intellectually) present at that time should be able to explain again.
One slide is practical to capture with a smartphone, and this slide contains everything; this advantage is really cool and I think that I will use this technique again when I don’t need to focus on a specific topic.
I was very concentrated with the data that I totally forgot a lot of details :)
Personal notes for later:
- Put at least my name, somewhere on the slide :)
- Say who I am when I start talking
- Don’t forget to add contact instructions
I was really happy to receive feedbacks from the students about the effectiveness of this style of presentation.
It was straight to the point, I like it
It was intense, I received a lot of motivational information, I want to know more now
My colleagues told me that a student asked her:
How are you so much energized, it’s impressive to feel so much energy
After the event
I made a lot of mistakes during the presentation and the preparation, but we also made some after :)
First, we forgot to create a job’s specific email address, it was fastly fixed, and the dedicated address (firstname.lastname@example.org) was shared to the students by the 42 staff (thank you Virginie!).
Why we attended this event?
Technically, we are not in the hurry of hiring anyone, but Alex and I, recently finished to read “Who”, and we decided to follow the concept of meeting people continuously, maintain a list of people with their talents, and contact them the day we are in the hurry of hiring someone.
Additionally, we are also open to “the perfect match”, and last but not least, I’m often solicited by other friends and CEOs of the startups I audit, so it’s always useful to take some time to meet motivated students, speak with them,
Even if we are not actively looking for a position, we made the exercise of defining what kind of profile would make the difference enough to hire someone right now.
We formatted our job offers as “Scorecards”, which is the method suggested in “Who”.
See Berty’s Scorecards (work-in-progress).
Do you code a lot? I do. Over the years I’ve written and open-sourced a lot of projects, many of which you can see here.
Now, a lot of the code I wrote felt right while I typed it – you probably feel the same way when you code. But then later, when I reviewed it, I found plenty of hiccups and gaps in it. And there was also a lot of code that could be polished.
No wonder then that at the end of almost all my early projects, I had to rewrite most of the code. Version 1 (V1) code didn’t really make it into the final product. It had to go out.
The Problem: Or How I Came Up with the “Trash V1” Rule
The fear of trashing code is certainly the number one reason for the technical debt. However, when you split your code you have way more chances to fail than to succeed.
Often, it’s tempting to spend a lot of time on a piece of code to “make it perfect”. But when you start a project, it’s hard to define perfection in a piece of code. You need the insight that only comes after you finish a version of the code to figure out what would make your code perfect.
If you try to make your code perfect from the start you know what will happen? It will be twice harder for you to trash it even if it’s faulty or just useless, for the simple reason that you’ve invested in it a lot of energy and passion.
I’ve been through all that. Most of my V1 code that I kept back in the early days was just regrets. Usually, I ended up rewriting everything, losing not just time, but adding more retro-compatibility constraints to the code.
You should never do that.
The “Trash the V1” Rule
Here’s where my rule comes in. It’s a simple rule. It consists of assuming that “nobody (not even me) knows exactly how we want to do the project.” Or, to put it in a different way, that not everybody is aligned with the final expectations for the project.
This rule is essentially an extra step that costs you only a few hours or days but that gives you an extra guarantee. The guarantee that you’ll be able to find the right code when following your roadmap.
At the same time, it’s also a good way to check if the project is interesting. You can consider it as a “trial period” during which you familiarize yourself with the project and understand it thoroughly.
Set this simple rule before you start coding. If you have a team, you should announce it to them before you get to work. This way, you ensure that nobody will lose time on an over-engineered, over-optimized piece of code that in the end fails to deliver the expected results.
Here’s a tip to make sure this rule really works for you: set a short time limit, let’s say 1 evening for a solo project or 2 days for a team project. For bigger projects, up to 1 week should be okay too, but the shorter the term, the better.
And here’s another tip: at the end of the proof-of-concept phase (PoC), even if the project is not yet finished, focus on the core value, on what makes it unique and better than the competition. There’s a chance that your project is already on its way to being “the best piece of software to achieve that thing” in the world.
Now, let’s take a step-by-step approach to implementing this rule. Follow these steps for best results, and to speed up your project too.
How to Implement the “Trash the V1” Rule
In the beginning, the most important thing is to stop trying to define all the specifications of what is yet an abstract project. Make the project as concrete as possible by focusing on what you know about it and only then define the missing specifications.
Focus on what makes the project unique and write the core specifications. So, what’s special about it? It can be an original feature or a significant difference compared to an existing solution.
Explain the rules to your teammates. Choose any additional constraint (time limit, framework/library/method to use) that can help keep you all focused.
Remind your teammates that everyone should avoid doing early-optimizations and over-engineering.
Code. Do it quickly, with the aim of creating a working version of the product. Don’t waste time on it.
Trash this code. Yes, trash it. Actually, you can just archive the repository in read-only mode and consider manually copying some parts later. It brings you some peace of mind.
Now, you have something concrete and you can write better specifications and a more accurate plan. Technically speaking, you are also able to demo your idea to your coworkers, family, friends, or investors.
Start a new codebase and write the V2 of the code. Ideally, this version should be the one you publicly release.
I use the “Trash V1” rule for every big or difficult project I undertake. I use it for personal projects as well as for team projects. Even if this rule seems more appropriate for project bootstrapping, it can also be applied to subparts or experiments in a later phase of the project.
Do you fear trashing code? You shouldn’t. Letting go of code you’ve written may not be easy but it’s beneficial.
If you overcome this fear and apply this rule, you’ll actually save time in the long run. In many cases, “Trash V1” will enable you to skip the first required rewrite that usually happens 6 months or 1 year into the life of the code.
So, make this rule a habit – trash version 1 of your code. It may be a bit scary at first, but you won’t regret it.