This is their container builder project re-branded.
Pretty nice product, but missing some LAUGHABLE features.
Specifically:
- Ability to start builds based on github pull requests
- Ability to send messages to slack on successful / failed builds
- Ability to update github PRs with build status
- Conditional build steps AT ALL
- Ability to start parameterized builds from GUI ( What if I want to deploy to a specific environment? )
- Any outside integrations AT. ALL.
- No story on how to store secrets
I've been running this product for about a year. I have a Jenkins job that detects github PRs, and then launches these builds. I would LOVE to delete that Jenkins VM, but for some reason a lot of basic functionality has been ignored.
edit:
People have informed me that Github PR building is in alpha! PRAISED BE THE GOOGLE!
As a student who SUFFERED through K-12, was an awful C-D student, I agree 100% with this overall idea.
I went from a D high school to a straight A student in college. I found the freedom to choose to study what I am interested in ( Computer Science ) extremely liberating. I found the respect shown by the faculty to the students refreshing compared to my high-school. I found that being able to leave, take a nap, and then come back for my next class much more tolerable. I found that not being locked in a building for 9 hours a day freed up time to actually study and get your homework done.
Basically, I discovered what everyone else already knew: Current schooling is intended to keep kids in child-jail while their parents are working. Most schools do not have the resources to cater to bored gifted students, so we are cast aside with the understanding that "we'll be fine" while sitting through remedial classes where we have to read out loud because some of the students in the classroom are illiterate.
People claim college is a waste of time? HA. HIGH SCHOOL is four years of my life WASTED that I will never get back.
Let students set their own pace for education. Have them take responsibility for their own lives and future at a younger age. Let the children out of child jail.
I've lived in the Midwest my entire life, from a tiny town of 2,000 people to Chicago Illinois. I'm moving out to Portland in less than a month.
I REALLY dislike the Midwest due to it's lack of natural beauty, epidemic of poor civil engineering and city design, and hostile climate.
> If you're looking to move to the Bay area, you should also look at moving to the like Lincoln, NE or Omaha, NE or Kansas City. A lot more so if you have a family. I know that sounds strange, but....
Comparing the job market of Lincoln, Omaha, or KC to the Bay Area is very flawed. The tech-hubs are a real thing, and there are advantages to working in an office that make remote work undesirable. ( More likely to be promoted, having a social life, etc. )
Even in cities like Portland, you look around at the jobs being offered and see MOSTLY lame fintech and insurance company jobs. Additionally, you are away from the critical mass of highly educated and motivated developers. Even here in Chicago, you meet a LOT of the b-team.
> The Midwest is cheap. Albeit harder than the past, it is still possible and common in the Midwest to live a middle-class-ish lifestyle on a single income. A two bedroom apartment can be less than $500 a month.
While it's true that you can get a large house for cheaper, what are you going to do while you are in these cities? They, full stop, lack the cultural and natural vibrancy of the Bay Area. Extremely homogeneous, poorly designed cities full of insurance salesmen and hicks.
Brutal cold winters and sweltering, buggy summers. Not that you would want to go outside anyway, since most of these Midwestern cities have declined to invest in walkable infrastructure and instead more resemble disconnected buildings joined by huge highways. You will drive everywhere and none of it will be interesting or beautiful. ( To be fair, I hear Columbus has some nice infrastructure )
Not that you would have anywhere to drive to. The nature sucks. You can drive out of town and see some beautiful... corn fields. And flat land. Filled with bugs. Nobody has bothered to forge hiking trails because there's nothing to see.
> I have friends with $830/month mortgage payments on their house.
The most expensive house is the one you can't sell. And housing is not an automatically good investment like many people believe.
I know from experience, a lot of my friends who bought cheap houses regret it now that they are interested in selling and NOBODY'S BUYING.
> The Internet is solid in the Midwest too...
True. You can do the job. If you don't mind working remote / find a good job in the Midwest, it is 100% viable to live there.
> Lastly, (this is a hot topic issue so I am reluctant to put it in, but it is something that comes up from my friends on the west coast) the states are red states, but the cities are blue.
Yes. This means every time you decide you want to get away from the city, you are greeted by a bunch of Trump-supporting, confederate flag waving yokels who cut the sleeves off of their shirts. Also this means that when those people want to get away from the country, guess where they go? Your city, where you have to interact with them.
It's amazing to me how people still "meh" away testing as a secondary concern, and then regret it later. Over and over again.
WRITING software is easy, anyone can do it. CHANGING software is extremely difficult. THAT is why we have tests. Also, if you are smart about it, you can get documentation out of the deal for relatively little additional cost.
My go to example is on-boarding new developers:
New dev: "OK, i'm here! How do I start?"
with tests: Clone the repo, install dependencies, and run the test suite. As you develop new features, be sure to write additional test.
They are up and going in a matter of minutes.
without tests: Clone the repo, install deps, download testing database, achieve homeostasis with your dev environment, learn the entire system, build up the state you require to write your feature, iterate on it by hand over and over again.
I did this a few years ago, started my own company.
I failed for two reasons:
1. I wasn't experienced enough as a developer IN THIS TECHNOLOGY to hit the ground running.
When you are self-employed, time = money. You don't have time to learn the technology, figure out your business, and write the code. You have to hit the ground running and burning time on ramping up is extremely expensive.
2. I lacked the discipline required to maintain myself while working extremely hard at my start-up.
Additionally, I didn't take good enough care of myself. I was ignorant about how to be productive. I was working all of my waking hours, martyring myself for my start-up and then getting up the next day and doing it over again.
Here's a tip: This is bad and leads to failure if you aren't careful with your time, food, and sanity management. A lot of people like to glorify this behavior but really, excellence is a 24-hour job.
Working out, eating well, getting a good night's sleep, and then coming into work the next day with clear-eyes beats running yourself ragged with panicked late-night programming sessions every time. ( Although, some people like to work at night and that is totally fine, we all have our own form of productivity. )
My point is really more about taking care of yourself and BEING DISCIPLINED. Unless you are wealthy, you do not have time ( remember, time=money ) to make mistakes. Discipline is your buffer between your degrading sanity and your ability to make good decisions.
It sounds like you have a dysfunction with decision making and productivity. This is something you need to deal with.
It's OK! It happens to a lot of people. This is something you can study and improve.
I highly recommend reading a few books on productivity and making good decisions in order to correct your behavior.
My recommendations are:
- Deep Work - Cal Newport
Will go into detail about how to learn new things and accomplish large projects.
- Smarter Faster Better - Charles Duhigg
Goes into the psychology of motivation, accomplishing large tasks, setting goals, and making better decisions.
- The Adventures of Johnny Bunko: The Last Career Guide You'll Ever Nee - Daniel H. Pink
A cheesy and poorly drawn manga-style career guide with some surprisingly good advice on career advancement and fulfillment. This one is a short read but I can't help but think back on it and reflect on it's lessons from time to time.
I'm a single-person ops team for my startup. Granted, I MAY be an exceptional learner and not realize it, but I mostly consider myself an under-achieving stoner.
I chose Kubernetes as our platform a few years ago and it's been absolutely wonderful and only getting better. Every once in a while I do a thought experiment with my co-workers to ensure Kubernetes is still the product for us. It is. We all love it and it makes my job easier. And it's really not that complicated.
Let's go ahead and list a few things Kubernetes Provides at the cost of writing a few YAML files and provisioning some docker containers in our CI/CD stack:
- Service discovery and health checks
- Zero downtime upgrades with rollouts and rollbacks
- Horizontal auto-scaling ( VM AND container )
- Configuration management and secret storage
- Immutable infrastructure
- Automatic SSL provisioning and routing via kube-lego and GCE ingress controller
- Log aggregation and monitoring via Heapster
- Cloud-provider agnostic configurations
- A consistent and approachable API to implement required features onto.
- ( With Google GKE ) Automatic security updates with a set maintenance window.
- Easy deployments with Kubernetes Keel
There are more benefits but these are the ones that come off of the top of my head.
ALSO, it's an opinionated framework that makes doing things "The Right Way" easy and intuitive to do.
In my TINY organization's reckoning, K8 actually makes our lives EASIER rather than more complicated and is considered one of the best decisions we ever made. It gets out of our way and lets us work on the fun stuff.
> In the case of applications that simply don’t have the scale problem, they usually don’t need the added complexity of a self-healing, horizontally scalable system.
If you build on a swamp your castle is going to sink into the swamp. Don't obsess over scale, but plan to scale, even if it's just "We can throw more servers at it."
Self-healing? The author is correct: Probably not necessary.
But scaling goes both ways: Our start-up is counting pennies and saving money wherever we can. Having an auto-scaling pod and node cluster makes so much sense. Our cluster automatically scales up and down based on load, saving us thousands of dollars a month.
> The problem I see with Kubernetes is that the cognitive load in the early parts of a project are simply too high. The number of things you need to create and worry about are a barrier to starting a project and iterating on it quickly. In the early days of a project, feature velocity and iteration speed are the most important factors. I view the Heroku model as the ideal development model. You have a managed hosted Postgres database and you just git push to get new code deployed and out the door. There’s very little to think about. It may not scale to infinity and it may get expensive, but you can worry about those things once you’ve actually got a hit on your hands.
I disagree with the assertion that starting out is difficult ( Or, that it is more difficult than other solutions ), and heroku is EXPENSIVE. With GKE, you are paying for the VMs and little more and get a BUCKET-LOAD more features.
What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.
You can have an application ready to go with three objects: a service, an ingress, and a deployment. I find Heroku to be of a similar complexity with less flexibility.
I get EXCELLENT monitoring and log aggregation by running `helm install datadog` and providing my key. I get a good-enough rabbitmq cluster by calling `helm install rabbitmq`. I get automatically provisioned SSL by calling `helm install kube-lego.`
So I suppose my response would be: No, I don't think it will. I think the complexity is over stated.
In my terminal everything is a string. All of my tools are run from the terminal ( cloud provider, provisioning software, etc. )
I can chain cli calls together to create powerful workflows.
I have highly scriptable workspace management with tmux + vim.
I don't have to wait for web pages to load to run commands, I can just do the thing in the same place I do everything else.
Many people don't gain that much from the terminal but if you are a power user it makes your life great.
I don't like GUIs, they take too much space, are always trying to sell me something, present information in an inferior way ( I like my dark, cool colored termina
l color palette ), and I can't script repetitive tasks.
most cli tools have the same conventions so learning new tools has way less overhead.
No. I don't think we do. Writing native apps is a huge waste of time and resources. While the big players in the OS space were squabbling the web browsers snuck in and drank their milkshake.
Browsers / web apps are a more portable, and more productive method of distributing GUIs. Full stop.
When deciding to go native or not, you have to decide: Will you hire several designated IOS application developers, several Android application developers, and have them re-implement your website? Or will you hire the equivalent amount of front-end engineers and have them collaborate and develop the codebase together using a shared toolkit?
People moan about how it's slow, but they tend to miss the point: I don't work for a "writing native apps and make the apps fast" company. I work for a software company that builds a product and sells it to users. Developer familiarity == Speed == Money
And really: Do you honestly believe spending 300k a year on engineers to re-implement the same shit we've already written, but in a different language with completely different semantics is a good investment? Rewriting all of the work we've ALREADY done for our mobile view in CSS and HTML and Javascript in Objective-C and Java?
Unless you're writing software with INTENSE graphical requirements, and even THEN there is webgl, writing a native app brings no value. You could spend that time optimizing your website written in JS you've packaged as an IOS/Android app. Or, I don't know, implementing new features and actually bringing value to your company.
PWAs are much slower, but as time goes on this will be improved.
As for the electron haters: Show me a more productive way to implement GUI applications. Show me the applications and frameworks that are putting out GUIs that look even remotely as good as the Electron applications.
I think we're going to see a rise of PWAs and apps that are simply web browsers in disguise.
Edit: I'll also add that the "not always online" or "bandwidth" argument is bunk. Crazy idea: Package your web application as an app, and include it's dependencies and everything it needs to run. Once you do that, the "download once" advantage of a native app is bunk.
I bought a Dell XPS for less than half the price and better specs. No regrets.
Apple hardware isn't that amazing, and even if it is, who cares. "Build quality" is just an excuse to spend more money on a luxury designer laptop that is becoming more and more hostile to its end users.
I dont need a thinner laptop or a dumb touch bar or a"minimalist" os design. I need decent Docker impl and ports to plug my phone and monitor into and to not spend $3k on a computer with mediocre specs.
The OS everyone loves to harp on about isn't as revolutionary as people like to pretend. Windows has better Docker support and that is a huge win in my book. Also windows doesn't make me enter payment info when I'm trying to install tools I need to compile my code.
For a few years I worked for a consulting firm. The laptop I chose was a $500 Lenovo with a decent processor and 1080p screen. I bought 32 gigs of RAM and an SSD and upgraded it. The cost of a comparable Mac is laughable.
Installed Linux on it. Used it for years, never had any issues, even with external monitors. The thing is still running to this day, though now I have it sitting under my TV as a media PC.
Ansible is similar to salt, but is imperative as opposed to declarative. I've found I prefer Ansible for the scale I work at. Salt has a better eventing and provisioning story though, and I can see the value in declaring your environment's "state" using pillars and states. There's just a lot more to Salt and I like Ansible's simplicity.
In Ansible/k8s_raw, you can declare your k8 resources in Ansible as real yaml, or you can template YAML using the jinja2 templating language, or you can generate YAML using a python library and use THAT yaml.
Ansible is a full-scale configuration management and provisioning library that happened to implement a Kubernetes module, whereas Helm is only a package manager.
I'm going to use this opportunity to get up on my soap-box and talk about helm, the "recommended" way to install kubernetes packages.
Helm is not a useful abstraction, and needs to change in a BIG way before I consider using it over k8s_raw and ansible.
My main complaint with helm is that it doesn't allow one to develop decent abstractions over the core kubernetes resources. IMO it needs to move away from `gotpl` and implement the ability to use more sophisticated templating libraries.
This block of code is in every single resource in every single helm chart. And it's one of MANY similar blocks of code that appear in basically every helm chart. I do not particularly enjoy writing the same massive YAML file over and over again.
Configuration management with helm is difficult. It would be nice to be able to declare "required" fields within an application, and enforce those fields with an error message if they are not provided. Currently, there is no way to do this other than having a "required" template that iterates through your "requiredFields" field and calls `{{ .Values.fieldName | required }}`
Interacting with the helm API server is difficult, which makes integrating helm with other configuration tools difficult. Specifically Ansible. This is also partly k8's fault ( And my fault, I suppose, because I could write it myself... ), because port-forwarding into the k8 server isn't implemented in any languages other than GoLang.
Keel does a really good job of this, good to see people are starting to have options with their k8 deployments!
My two cents:
So far my deployments have been pretty painless, so changing over to something like Gitkube / keel isn't my top priority currently.
Configuration management / Creating my kubernetes resources ( deployments / services / ingress / etc. ) in a repeatable and elegant way is my biggest pain point by far.
# Helm
I've been very unhappy with Helm.
Helm is insanely verbose. Go ahead and take a look at the kubernetes/charts repo and look at the various stable charts. Note the huge amount of copy-pasta code hanging out.
Too much of my life has been spent wrangling YAML templates that are rendered using the under-featured gotmpl library.
Also, helm's client library support is less than stellar. Also, schlepping my configurations around is a pain.
In Helm, it's a crazy amount of code to implement a `ingress -> service -> deployment` pattern that is standard for 99% of kubernetes resources. You have to write the same things over and over, which means that making changes takes forever and is brittle.
I believe this is due to gotmpl being a poor templating engine for this use case. It doesn't have enough features to allow one to develop decent abstractions over declaring k8 resources
The helm tiller doesn't expose a restful API or proper tooling to allow other resources to interact with it effectively, making automated deployments a chore. My only option is to call out to the shell and try and be devensive.
Finally, Helm doesn't really do that great a job of validating my resources are going to be valid. `helm install --dry-run` will tell you everything is great, and then break in the middle of an actual installation, leaving a half-configured mess in it's wake.
# KSonnet
KSonnet looks like an attractive option, it's certainly less verbose. But the documentation isn't there yet, and if you peek under the hood there is a MOUNTAIN of ksonnet code waiting to be read and understood. I belive it's going through some churn currently, so features and impovements have been slow to appear.
Also KSonnet doesn't have enough example implementations to hit the ground running when trying it out on my clusters.
Targeting individual contexts in Ksonnet provides some nice additional safety, and some very simple implementations using google KMS or something similar could be a really special way to safely store my secret configs at rest, similar to ansible-vault.
# Terraform
Terraform has this NAILED in the VM space. I declare my environment: `terraform plan` tells me what is going to happen, `terraform apply` checks to ensure I've not protected any of my resources with a flag, and applies the changes it listed if not.
I'd love to write my k8 resources in terraform, but it doesn't currently support modern k8 resources, and I don't LOVE how terraform handles storing my tfstate files either way.
Pretty nice product, but missing some LAUGHABLE features.
Specifically:
- Ability to start builds based on github pull requests
- Ability to send messages to slack on successful / failed builds
- Ability to update github PRs with build status
- Conditional build steps AT ALL
- Ability to start parameterized builds from GUI ( What if I want to deploy to a specific environment? )
- Any outside integrations AT. ALL.
- No story on how to store secrets
I've been running this product for about a year. I have a Jenkins job that detects github PRs, and then launches these builds. I would LOVE to delete that Jenkins VM, but for some reason a lot of basic functionality has been ignored.
edit:
People have informed me that Github PR building is in alpha! PRAISED BE THE GOOGLE!
https://cloud.google.com/cloud-build/docs/run-builds-on-gith...