We take the convenience of FreeBSD for granted

tuaris

tuaris

I was recently tasked with building out some infrastructure for a few PHP based web applications. This is at a place that runs Linux and Docker in production (yuk🤮), and of course like every other naive organization out there they use cloud services such as AWS and advertise to the world they run 'containers'.

Normally this is a super easy task. I'd get a few EC2 instances launched with the latest copy of FreeBSD, provision the jails, install PHP/Apache on each, configure different listening ports, deploy the code, then configure the AWS load balancer as needed. It's all very simple and straight forward.

With Linux I was baffled by how complicated things got. I'm no stranger to Linux or it's vast ecosystem of containerization solutions. The world strongly associates "Linux" and "Containers", but when you really get into it, that is far from the truth. Out of the box (unless you are a kernel developer) you really have no accessibility to the supposedly "built-in" containerization technology that everyone boasts about.

In Linux (depending on your 'distro'), you need to setup a 3rd party package repository, then install the container run-time, the tools, along with a ton of other dependencies. All to just get the basic functionality that's available in FreeBSD's base system. To make matters worse, many of these 'open source' 'solutions' are commercial or freemium that ask you to give up your privacy. As if that wasn't enough to deal with, you also have massive variations in configuration methods, functionality, and bugs. Even just across different versions.

In the end, what would have taken me just under a half-hour on FreeBSD took me close to 3 hours on Linux (not because of a learning curve). You also end up with something that in my opinion is sub-par when compared to the elegance of doing it on FreeBSD. Why do people accept this? Maybe they just don't know that something better exists?

We take our FreeBSD for granted, that's for sure.
 
Probably the same reason that a lot of places use Windows/Mac for their purposes. When they learned how to do it, they learned on Linux, whether at home from friends, or at school, and so that's what they continue to use. This is just a guess of course, not an answer from any actual knowledge.
 
We use Docker at work, and I just have to bite my tongue a lot of the time. The pattern we (and I guess a lot of people) use is "download a pre-built image and do something with it" - which means that each image is highly specialized. We end up building stuff in one image, copying the results into another image for additional processing, and maybe copy the results back to the original... because why on earth would you pkg install -y dep1 dep2 when you can have this level of convenience and isolation?!
 
Probably one of the great challenges FreeBSD is facing on its growth path to "become more popular" (note the quotes) is extending basic functionality by improving its building blocks, strengthening architecture fundamentals and increasing coherance combined with excellent documentation, while at the same time not giving in to featuritis. I like initiatives like Enterprise Working Group - bhyve+jails manageability work stream
 
I must say, I find Docker complex, but it helps in some very nice ways.
I wonder if in FreeBSD, at some point the idea of immutable 'building blocks' catches on like it has in the Enterprise software world.
To me, it really does help scale your infrastructure. There's a break-even point for me, where I think it starts to make a lot of sense to adopt something like Docker. You know, the point where you have say a 50+ software engineers on one platform, with 6+ different apps, that are building up to release updates every day.

At that point I don't mind considering the platform a deployable and just let the devs deal with it. Run automated security checks and let the devs deal with getting their app running. If it stops working, let's try again from scratch: this is an operation done within a minute, as a restart should clean up any state that isn't explicitly connected via volumes.

But FreeBSD Jails.. to me they are quite a bit nicer than what I consider it's equivalent: LXC. LXD would have been about equivalent, maybe a little easier than Jails, but back in the day I had some design and political problems with it. These are just plain old virtual machines to me though. It's great technology, but won't help a dev in any way, shape or form.

Just dealing with the complexity of software development should be more than enough for a dev so if standardised (even if it's a little more complicated) infrastructure would help them with familiarity, I'm for it. Especially if it's a great tool for shifting responsibilities, which might make sense in some organisations.

And so I believe having a 'deployable' oriented developer platform makes sense and is something FreeBSD doesn't deliver at the moment.
I've previously worked on getting devs deploying more efficiently to FreeBSD and it was a significant amount of work to get the bare essentials going. Compared to Docker, it's magnitudes more work. I'd advocate for a developer-oriented platform experience on FreeBSD any day of the week.
 
There are many ways containers are abused and misused but they're a wonderful technology when used right.

Part of the reason I came back to FreeBSD was to try jails. Same with OpenIndiana to experiment with Solaris Zones.

With Linux, containers are built from namespaces, cgroups and hardened with either SELinux or Apparmor + seccomp. With FreeBSD, Jails are built for security from the ground up. I see a lot of potential here.
 
Erichans said:
Probably one of the great challenges FreeBSD is facing on its growth path to "become more popular" (note the quotes) is extending basic functionality by improving its building blocks, strengthening architecture fundamentals and increasing coherance combined with excellent documentation, while at the same time not giving in to featuritis. I like initiatives like Enterprise Working Group - bhyve+jails manageability work stream
Click to expand...
Do You understand what they want, besides the ideology?

The ideology seems clear: have poor people build for free the thing that rich people need to get richer. That's the way we as a race managed to achieve something, thats how we got to build the pyramids.

But much more interesting is the question, what kind of pyramid should actually be built (i.e. Maya or Egypt?)

Probably it is just that I am lacking some understanding: for instance, I do not know what is the big difference between AWS-EC2 and a computer system (KVM or physical), and why I get told that AWS-EC2 is the holy grail of computer science and all former IT knowledge now worthless.
So I imagined this AWS-EC2 would now give you the readymade lampstack at a button-click, another click and the backup-solution is in place, one more click for high-availability, and finally a click for the security solution and the intrusion-defense-arrays (oh, maybe some more buttons for SingleSignOn, access management and monitoring). Because that is what I was told: IT-skill is no longer desireable, because people can now instead buy cloud. In other words, people can now install a server infrastructure by clicking on their windows explorer like they are used to.

But, the OP article sounds like this is not really the case.
So what is actually the case?

Obviousely the usual culprit will feel offended by the suggestion to write something like this:
Code: 
guest_conr_mem="640M"
guest_conr_cpumap=5
guest_conr_flags="-AHPSu"
guest_conr_ifcreate="tap0 tap1"
guest_conr_ifconfig_tap0_1="inet6 fe80::1%tap0"
guest_conr_ngbridge_tap1="upl_vlan:vlan7:7"
guest_conr_route_1="-net default 192.168.0.1"
guest_conr_restart="YES"

And indeed, this is not clickable.
But then, what would be?
 
patmaddox said:
Using Boot Environments at Scale

and

View: https://www.youtube.com/watch?v=5oHLU9w1vVk
Click to expand...
If we had this, 8 years ago, by installing a single thing, and a relatively simple interface.. I'd've loved to have used this.
The technology is there, it's just a significant amount of work, research and maintenance to keep something like this. A random web developer can't install this onto their machine on an afternoon. And these don't really seem to offer a relatively simple language or interface to manage their aspects.

I'm not trying to throw shade or be disagreeable, but for small organisations, this just doesn't seem like a feasible option. It's just so risky.
The question for me is, how can you generate community uptake, so that all these problems get resolved? Since you're not first to market anymore, that's an uphill battle. So ideally, we'd have unique, highly desirable features that people that haven't adopted Docker would want and/or would make people want to switch.

Simplicity would be a great start, but community uptake doesn't seem dependent on that in my experience. You need something valuable that you can't easily do elsewhere. Something that makes people get their stuff to market more efficiently is usually a good one. Trick is figuring out what that would be...
 
You must log in or register to reply here.
Back
Top