
Google Skaffold – Easy and Repeatable Kubernetes Development - nikolay
https://github.com/GoogleCloudPlatform/skaffold
======
antoncohen
Reminds me of Draft from Microsoft
([https://github.com/Azure/draft](https://github.com/Azure/draft)). It also
targets what they call the "inner loop" of the development workflow.

It looks like Skaffold watches for code changes, and Draft doesn't. But Draft
automatically creates the Docker and Kubernetes configs, while Skaffold
requires you to create (or copy and edit) them.

~~~
ppog
Draft can watch for code changes via a `watch` setting in draft.toml.
(Disclosure: I work on the containers team at Microsoft.)

~~~
majewsky
Not directed at you specifically, but what is it with people these days
feeling the need for a "disclosure" when just stating plain hard facts?
Disclosures are only necessary when you state an _opinion_ about something
that you are involved with.

~~~
jacques_chester
It's easier to be over-honest, honestly.

Disclosure: I suspect I am partly responsible for the "Disclosure:" thing
become a fixture.

------
tyingq
The shortfall, currently is some sort of long-term-supported version. Google's
GKS and Amazon's (currently beta) EKS, seem to be the answer for the spaces
I'm in. Love K8S, but not wanting to manage it like I currently manage
operating systems.

The pace of K8S versions, and subsequently things like ingress controllers for
various tech stacks, is currently a whirlwind.

~~~
tedmiston
AWS Fargate will be interesting too. But, like you said for EKS, it's still in
private beta as well.

I'm also keeping a pulse on riff [1] as a k8s FaaS.

[1]:
[https://github.com/projectriff/riff](https://github.com/projectriff/riff)

~~~
tyingq
That's great, thanks for sharing. I'm currently the "why don't we wait a
little" guy in a F500 where apps are trying to manage their own K8S installs.
Still feel pretty strongly that "just wait a bit" is the right answer. I'm not
loved at the moment for that opinion ;)

~~~
jacques_chester
If you need an F500-friendly kubernetes platform, Pivotal has PKS. Red Hat has
OpenShift. I imagine either of us would be happy to listen to what's worrying
you.

Disclosure: as you might have guessed, I work for Pivotal.

~~~
tyingq
I’m aware, but the licensing implications for highly elastic environments are
suboptimal for both RedHat and Pivotal at the moment.

Thus, I continue to wait for the big 3 cloud providers to figure it out.
Unrelated, but seems like an opening for Linode or DigitalOcean.

~~~
joeevans1000
Can you elaborate? Not at all a doubter here of what you're saying... could
just benefit from a tl&dr as I'm not likely to sort licensing issues out on my
own.

~~~
tyingq
Just adds another set of pricing complexity on top of AWS's. Look at the
pricing for either and you'll see the per-hour plus limits on vcpu or memory,
charges for going over the limit, etc.

~~~
jacques_chester
PCF is not licensed according to inputs (cores, memory). It's licensed by
application instance -- ie, the output of what you bought from us. If you run
one giant app with all the CPUs and RAM you can muster, that counts as one AI.

We like this model because (1) it roughly approximates the added value our
customers derive and (2) it's easy to calculate without disagreement.

We _do_ bill PWS based on total RAM-minutes, but that's simply because the
existing hosted-PaaS market assumes that model. Our price for PWS is pretty
close to what it costs us to run the bits on AWS.

Of course, I should emphasise, I do not work in the sales side of things,
where prices can be discussed and Baldwin quotes abound. But I kinda like the
sales folk in my office, so if you want to meet one, please email me.

------
cygned
We are moving to Kubernetes at the moment. What is still miss is this “just
run docker-compose up and everything works” setup. Maybe this or Draft from
Microsoft is something to look into.

~~~
modernpacifist
You can sort of achieve the same outcome just my having all the various
services/container specs inside a single .yml file that gets fed to 'kubectl
apply'. docker-compose up does create networks and containers unique to the
app your developing, but you could have the .yml setup a custom namespace and
pile everything into that and get close. No option to concat all the log
output though AFAIK.

~~~
xnxn
I use stern for multi-pod log tailing:
[https://github.com/wercker/stern](https://github.com/wercker/stern)

~~~
ah-
I've switched to [https://github.com/boz/kail](https://github.com/boz/kail)
now, as stern seems to somehow miss pods coming up.

~~~
alpb
There's no shortage of tools that do the same thing in Kubernetes universe :)

[https://github.com/johanhaleby/kubetail](https://github.com/johanhaleby/kubetail)

------
agency
This looks interesting, but having to perform a Docker image build (even if
most layers are cached) as part of your iteration loop seems potentially slow.
We use minikube to run local stacks but have been using telepresence[1] to
swap out services for ones running from a local build (outside of a container)
with incremental compilation and hot reloading and all of that good stuff.

[1] [https://www.telepresence.io/](https://www.telepresence.io/)

~~~
jacques_chester
Telepresence is really neat, I saw a demo last week from another team member.

Speeding up builds is something I'm interested in. Google's FTL is one good
solution; I think we'll see some more from their container tech team before
long. Personally I've pitched a notion based on automatically building layers
for "synthetic" images by identifying commonalities between filesystems.

~~~
dlor
Hey Jacques,

Do you have any more info on the idea about identifying commonalities between
filesystems?

I work on Skaffold and really want to speed up builds.

~~~
jacques_chester
Hit me up on my work email and I'll send you a link to a doc I've shared with
some of your colleagues (jchester@pivotal.io).

------
alpb
Mods probably should consider updating "Google Skaffold" to "Skaffold by
Google" as that's not the project name.

~~~
nikolay
Agreed. Only @dang can change it now as editing is now disabled.

------
rad_gruchalski
Cool, looks interesting. I just spent a couple of weeks getting a k8s setup up
and running on AWS, from zero. As much as I appreciate these sort of
platforms, I did enjoy learning the inner details of how k8s components
communicate together and how they work.

------
davidbanham
This looks really interesting. I have a project that does something similar
for the remote deployment but uses only make and kubectl.

[https://github.com/davidbanham/kube_maker](https://github.com/davidbanham/kube_maker)

I've been thinking about integrating a local minikube lately but haven't
started yet. I may end using Skaffold as a backend or just deprecating
kube_maker entirely if it becomes obvious that Skaffold is the way to go.

------
darren0
I find it odd when I see projects in the GitHub org
github.com/GoogleCloudPlatform like this one. Being that the org has the same
name as Googles product (GCP) I would not expect experimental or nacent
projects. I never know what to expect. Is this an official Google product that
will be supported or some experiment by some devs in Google.

~~~
fredsted
No matter what, it's probably best to expect that Google may deprecate any
feature or project at any time.

------
philip1209
This looks promising. My main concern is whether it requires changing the way
code is built and deployed too much.

For instance, I don't want `npm run build` to be executed every time I change
a Javascript file.

