Create user-story #17
Conversation
| @@ -0,0 +1,124 @@ | |||
| A Year In The Life Of A Kubernetes Service Developer | |||
There was a problem hiding this comment.
@judkowitz can you make this a markdown header format?
# A Year In The Life Of A Kubernetes Service Developer
There was a problem hiding this comment.
I think I got the markdown correct. Having trouble previewing the result for some reason...
| some co-workers to be able to find the chat app to connect. So, I register it as a service in kubernetes service. It keeps | ||
| track of the IP address and the port of the app for us which is nice because I keep moving the thing around. It started on | ||
| minikube on my laptop, but now it’s in the company’s kubernetes deployment on our OpenStack private cloud. Also, I have to | ||
| change the port number from time to time because of conflicts, so a centralized place to find the app is really nice. |
There was a problem hiding this comment.
@judkowitz does this mean you have to change the port number because other containers are running in the same pod?
There was a problem hiding this comment.
This was not an important detail. I'll just delete the point. I was just trying to describe what the existing service construct gave us.
| @@ -0,0 +1,124 @@ | |||
| A Year In The Life Of A Kubernetes Service Developer | |||
|
|
|||
| 0. Today | |||
There was a problem hiding this comment.
same here regarding the markdown header format. maybe consider using ## as a subheader?
There was a problem hiding this comment.
I think I got the markdown correct. Having trouble previewing the result for some reason...
| delivered. I hoping to avoid the work of picking a system and learning it. The good news is that when I was looking at the | ||
| kubernetes service catalog the other day, I saw a RabbitMQ instance that someone else was maintaining. All I needed to do | ||
| was issue a single command to bind my chat app to the Rabbit service (and, of course, edit my software to use Rabbit). The | ||
| bind call gave back credentials which automatically discovered by my chat app and it was off to the races. I have no idea |
There was a problem hiding this comment.
"which were automatically discovered by my chat app"
| where that thing is running or how the firewalls work, but whatever, I trust it since it’s maintained by corporate IT. | ||
|
|
||
| 2. Make a type from a kubernetes service | ||
| 3. Share service types inside an org |
There was a problem hiding this comment.
are (2) and (3) still to be completed?
There was a problem hiding this comment.
Not sure what you mean about "still to be completed". Only 0 is in kubernetes now. 1-14 are all what I think this SIG should enable.
Am I understanding your question correctly?
|
|
||
| 14. Update type, create update template, and redeploy service | ||
| So, I do for my service what the the database people did for me. I created a new version, tested it out, and deployed it to | ||
| the catalog (without any marketplace in the way, since this is an internal app). Now, I’m getting messages about my chat |
There was a problem hiding this comment.
This is the second time the marketplace was mentioned, but it hasn't been described. Since this is a user story doc, it might be good to indicate exactly why and how you, the app developer, would use it.
Also, it'd probably be good to add to the root README.md document as a term. It seems to be a new concept that I've overheard a few times in passing.
There was a problem hiding this comment.
Excellent points. I did not want to write a marketplace story, but the assumption is that the marketplace exposes the broker interface but that there are additional up front steps before you get to call that broker where you have to sign-up, pay money, etc...
So, when you call a service broker from the marketplace, its schema probably demands some token or identification that validates that you are someone that has the right to accrue usage against a particular entitlement.
This idea of having a common broker interface for private catalogs and public marketplaces and a common developer experience between the, seems very powerful to me. (And, that similarity of interface is why I didn't add any extra text about the experience)
Thoughts?
| as well. It’s a good thing I got the notification or I’d have never known. Thanks Kubernetes! | ||
|
|
||
| 14. Update type, create update template, and redeploy service | ||
| So, I do for my service what the the database people did for me. I created a new version, tested it out, and deployed it to |
There was a problem hiding this comment.
I'm a little unclear on how & why the chat app would go into the service catalog. So far, we've only talked about the catalog in the context of services that have a software-consumable API.
Are you suggesting here that it may also contain services that end-users (like the support team described herein) can use?
There was a problem hiding this comment.
Follow up question if that is what you're suggesting: did you have to design your chat app in a specific way, to accommodate multiple organizations wanting their own chats (in other words, did you have to do something special to accommodate multi-tenancy)?
There was a problem hiding this comment.
My assumption is that end user facing apps could also be there. I'm thinking about it from an operator's perspective. I have a large app with a microservice architecture that is made up of many smaller services bound together. I want to be able to see all the pieces of the app, the front end, the back end, the persistence layers... Having a list of all the microservices except the front end (because it has no consumable API) is kinda weird. I want to understand the whole app, all its parts, and how the connect together..
I guess this gets to a debate about whether "everything is (or can be) a service" vs. the Cloud Foundry model of "apps are apps and services are services". When everything is two tier - apps bind to services, I can see the latter POV. But, when you look at the recursive model where the thing that is bound to can bind to something else which can bind to yet another thing, the app/service distinction kinda breaks down and everything looks like a service (Some standalone and some composite. Some that are bound to, some that bind to others, and some that do both),
As for the multi-tenancy of the app, I'm assuming that's all logic inside the app at this point.
| using bigger containers and not just keep scaling out more and more tiny ones. (Not only did the immediate problem go away, | ||
| but paradoxically, the cost went down which was nice - they solved another problem I’m sure I would have had next quarter) | ||
| But, now we need to roll this out more deliberately so that the setting sticks and that new instances are deployed properly | ||
| as well. It’s a good thing I got the notification or I’d have never known. Thanks Kubernetes! |
There was a problem hiding this comment.
I'm a little confused how the alerts and compliance for your chat app fit in here. Did you, the app developer, set those two features up yourself, or did they come into existence some other way?
There was a problem hiding this comment.
Yeah, I'm making some assumptions here - sorry about that. My assumption is that when a service instance is deployed from a broker that any deviation in running state from what the broker instantiated it with would be flagged. I'm assuming that there are a few types of config
- Things hard coded in the Class' template - any deviation is flagged
- Things that are configurable in the deployment schema - can be changed when you do an update without changing the Class at all. But, if you change the running state without the update should be flagged
- Things that are fairly variable such as number of replicas - as long as that is between the minimum and maximum set in the template and/or deploy time config, there should be no flagging
As I write this comment, I realize how expansive this is. I understand if it's contentious and/or deferred outside v1. But, I think it's a nice vision for enterprise collaborative development environments.
There was a problem hiding this comment.
This part is a little murky for me too. Need to think about this.
| with minor modifications. I choose between blue-green (where traffic is distributed between the versions), deploying a new | ||
| version entirely and having a cutover, and per customer traffic splitting. Per customer won’t work because I really only | ||
| have one customer (the support app itself) and full cutover seems risky no matter how much testing I do. So, I select the | ||
| blue/green update option and give it the arguments that tell it how fast to ramp from 10% to 100% on the new version. |
There was a problem hiding this comment.
did you, the app developer, use deployments here?
There was a problem hiding this comment.
I should know more about how this interacts with deployments. Maybe the broker here just uses the deployments APIs for rollouts. I can work with some of the engineers to make a more explicit story here.
There was a problem hiding this comment.
I'm pretty hazy on this area. Need to think further.
|
@judkowitz can you wrap lines at 80 or 100 chars? Makes it easier to review on github. |
|
@pmorie I think I have the line wrapping fixed. If not, let me know. |
| @@ -0,0 +1,123 @@ | |||
| # A Year In The Life Of A Kubernetes Service Developer</H1> | |||
There was a problem hiding this comment.
nit, you can remove the ending h1 tag here
There was a problem hiding this comment.
Also, this file should be named user-story.md
| # A Year In The Life Of A Kubernetes Service Developer</H1> | ||
|
|
||
| ## 0. Today | ||
| I’m building a node.js chat application for me and a couple of coworkers to goof around with. It’s really simple. It runs |
There was a problem hiding this comment.
Add a sentence where you identify the narrator?
| ## 0. Today | ||
| I’m building a node.js chat application for me and a couple of coworkers to goof around with. It’s really simple. It runs | ||
| on one container. To get going, I simply download a node.js container onto minikube on my laptop and started coding. I | ||
| want some co-workers to be able to find the chat app to connect. So, I register it as a service in kubernetes service. It |
There was a problem hiding this comment.
'service in kubernetes service' -> 'service in the kubernetes service catalog' ?
There was a problem hiding this comment.
I'm not sure that the above is what you meant, some disambiguation needed here
| keeps track of the IP address and the port of the app for us which is nice because I keep moving the thing around. It | ||
| started on minikube on my laptop, but now it’s in the company’s kubernetes deployment on our OpenStack private cloud. | ||
|
|
||
| ## 1. Bind kubernetes whitebox services to an internal blackbox service |
There was a problem hiding this comment.
I'm unclear on what the whitebox element is here -- is it your chat service?
| bind call gave back credentials which were automatically discovered by my chat app and it was off to the races. I have no | ||
| idea where that thing is running or how the firewalls work, but whatever, I trust it since it’s maintained by corporate IT. | ||
|
|
||
| ## 2. Make a type from a kubernetes service |
There was a problem hiding this comment.
Do you plan on expanding (2) and (3) here before this is merged? If not, I would comment them out and add them when there is text for them.
There was a problem hiding this comment.
Sorry, what I mean here is that 3 different activities here - 2, 3, 4 - are all described in this part of the story. I could only describe the three steps together in one flow even though they are three discrete things that need to be done.
| DB upgrade... | ||
|
|
||
| ## 12. Upgrade service instances to new service type version | ||
| Wow, the version upgrade was just as easy as the “small” to “large”! All I needed was one update command and the database |
There was a problem hiding this comment.
I think more detail is needed here - what is the upgrade process really like? The current text makes it sound like it was a live upgrade, but then says it was tested for a week. It might be useful to elaborate a bit here on what you expect this process to be like.
There was a problem hiding this comment.
Since the service is managed behind the broker, the narrator has no idea. I can imagine what a DB upgrade would look like and the narrator probably can as well. But, the complexity is hidden behind the broker, which is really the whole point and the power of the model.
To your point, though, the reason that I have a story around the narrator's upgrade of his own code is because, as you note, we need to see that as readers. Can you defer your interest in this to that later point in the story?
| using bigger containers and not just keep scaling out more and more tiny ones. (Not only did the immediate problem go away, | ||
| but paradoxically, the cost went down which was nice - they solved another problem I’m sure I would have had next quarter) | ||
| But, now we need to roll this out more deliberately so that the setting sticks and that new instances are deployed properly | ||
| as well. It’s a good thing I got the notification or I’d have never known. Thanks Kubernetes! |
There was a problem hiding this comment.
This part is a little murky for me too. Need to think about this.
| as well. It’s a good thing I got the notification or I’d have never known. Thanks Kubernetes! | ||
|
|
||
| ## 14. Update type, create update template, and redeploy service | ||
| So, I do for my service what the the database people did for me. I created a new version, tested it out, and deployed it to |
There was a problem hiding this comment.
'deployed' is probably not the best verb to use here because there is another 'deployment' concept already in Kube which is something different. Can we use 'publish' instead?
There was a problem hiding this comment.
How about, "update the service instance"?
| app for tech support being out of date and the tech support people are calling me asking me if I knew that the app had a new | ||
| version (well, yeah, I know, I created it :-). I guess those notifications really work… But, now I’m the guy who needs to | ||
| build the update service broker and I’m worried about that. It’s not what the database vendor went through, thankfully, | ||
| because the chat app is stateless. One of the default update service brokers that come with kubernetes should just work |
There was a problem hiding this comment.
Not sure what a 'default update service broker' is
There was a problem hiding this comment.
Yeah, I'm murky on this as well. My point is that there should be a default service broker that has some upgrade logic choices that the author can choose from and configure easily by changing a few things. I think it will be hard to get people to write brokers from scratch.
| with minor modifications. I choose between blue-green (where traffic is distributed between the versions), deploying a new | ||
| version entirely and having a cutover, and per customer traffic splitting. Per customer won’t work because I really only | ||
| have one customer (the support app itself) and full cutover seems risky no matter how much testing I do. So, I select the | ||
| blue/green update option and give it the arguments that tell it how fast to ramp from 10% to 100% on the new version. |
There was a problem hiding this comment.
I'm pretty hazy on this area. Need to think further.
| # A Year In The Life Of A Kubernetes Service Developer | ||
|
|
||
| ## 0. Today | ||
| I'ma developer in an enterprise environment. For some fun in my spare time, I’m building a node.js chat application for me |
| ## 0. Today | ||
| I'ma developer in an enterprise environment. For some fun in my spare time, I’m building a node.js chat application for me | ||
| and a couple of coworkers to goof around with. It’s really simple. It runs on one container. To get going, I simply | ||
| download a node.js container onto minikube on my laptop and started coding. I want some co-workers to be able to find the |
There was a problem hiding this comment.
I kind of think that the rest of this section, starting with "I want some co-workers..." until the end of the paragraph, should be another section. I think that section should describe in more detail how registering this service in the catalog means that there is a stable endpoint for its consumers.
There was a problem hiding this comment.
I also sort of feel like the progression of this story might be easier to digest if the narrator begins with consuming a service. To me consuming a service is the most primitive use-case and running your own broker is a more advanced one. So, maybe the flow can be:
- Narrator makes chat app in local kube
- Narrator consumes rabbit MQ service
- Narrator needs to move off of local kube, registers in service catalog...
There was a problem hiding this comment.
Isn't that how the story goes (more or less)?
- Narrator makes the story in local kube
- no types
- no brokers
- no service catalog (unless I created confusion with him using the existing "service" construct)
- Narrator uses RabbitMQ
- Though I did have the app on the corporate kube already which makes sense - chat app should not die when narrator closes laptop
- Narrator registers in service catalog
- That only happens at the point where someone wants to bind to it (tech support team)
Am I misunderstanding?
| I'ma developer in an enterprise environment. For some fun in my spare time, I’m building a node.js chat application for me | ||
| and a couple of coworkers to goof around with. It’s really simple. It runs on one container. To get going, I simply | ||
| download a node.js container onto minikube on my laptop and started coding. I want some co-workers to be able to find the | ||
| chat app to connect. So, I register it as a service in service in the kubernetes service catalog. It keeps track of the IP |
There was a problem hiding this comment.
Moving the app from laptop to prod, across networks, etc. is fairly unrealistic, but it does raise the issue of how to invalidate binding information.
There was a problem hiding this comment.
Why unrealistic, exactly? Until we do all the advanced functionality, the app is just a container. The narrator can deploy that anywhere as long as he tells the users what the chat IP and port are
| I'm a developer in an enterprise environment. For some fun in my spare time, I’m building a node.js chat application for me | ||
| and a couple of coworkers to goof around with. It’s really simple. It runs on one container. To get going, I simply | ||
| download a node.js container onto minikube on my laptop and started coding. I want some co-workers to be able to find the | ||
| chat app to connect. So, I register it as a service in service in the kubernetes service catalog. It keeps track of the IP |
There was a problem hiding this comment.
s/as a service in service/as a service/
| and a couple of coworkers to goof around with. It’s really simple. It runs on one container. To get going, I simply | ||
| download a node.js container onto minikube on my laptop and started coding. I want some co-workers to be able to find the | ||
| chat app to connect. So, I register it as a service in service in the kubernetes service catalog. It keeps track of the IP | ||
| address and the port of the app for us which is nice because I keep moving the thing around. It started on minikube on my |
There was a problem hiding this comment.
An ever changing IP might be kind of interesting - we should pull that into a separate usecase and track it.
| # A Year In The Life Of A Kubernetes Service Developer | ||
|
|
||
| ## 0. Today | ||
| I'm a developer in an enterprise environment. For some fun in my spare time, I’m building a node.js chat application for me |
There was a problem hiding this comment.
funny, this is pretty much how http://soaphub.org/conf got its start
| kubernetes service catalog the other day, I saw a RabbitMQ instance that someone else was maintaining. All I needed to do | ||
| was issue a single command to bind my chat app to the Rabbit service (and, of course, edit my software to use Rabbit). The | ||
| bind call gave back credentials which were automatically discovered by my chat app and it was off to the races. I have no | ||
| idea where that thing is running or how the firewalls work, but whatever, I trust it since it’s maintained by corporate IT. |
There was a problem hiding this comment.
I think I understand where you're going with this, but, are the chat clients users of the queue? Meaning, do they each individually talk to RabbitMQ? I'm not sure that's the right scenario to go after, but we can chat.
| database without hiring a DBA, life would be great. A friend of mine works at a database company that sells and manages | ||
| databases on the public cloud that we use. She told me that if I was using Kubernetes or Cloud Foundry, this was trivial to | ||
| solve. They implemented the exact same service broker model I had to implement. I just needed to buy their database from | ||
| some store and with one API call they will deploy a managed database instance to the same cloud as my chat app and with a |
There was a problem hiding this comment.
"deploy a managed database instance to the same cloud as my chat app".... hmmm
k8s-ci-robot
added
the
cncf-cla: yes
|
@kubernetes-incubator/maintainers-service-catalog PTAL |
| deploy my chat service the same way that they deploy everything else in the company. I check it out and it’s pretty cool - | ||
| creating the broker and setting up the parameters to deploy the service on command is a <simple process>. Now I can deploy | ||
| the service with a single command. Even though it was not hard to deploy for me before, it’s easier now even and the | ||
| interns are always deploying within the constraints I set. And, most importantly, the interns nowhave no problem deploying |
There was a problem hiding this comment.
needs a space between now and have
|
I understand that @pmorie is gonna do a follow up, so I'm LGTMing this as-is |
|
LGTM |
1 similar comment
|
LGTM |
patch: add upstream version in catalog logs
… (CRDs) solution (#2630) * Add basic validation to crds * Add webhook skeleton, remove api-server from chart, add webhoook server in chart, move PrepareForCreate login into webhook handler (#2) * Add webhook skeleton, remove api-server from chart, add webhoook server in chart, move PrepareForCreate login into webhook handler * Add logger and GVK matcher * Add test coverage for webhook (#6) * Add Status entry initialization in binding and instance controller (#5) * Change fs to label selector (#9) * Fix removing finalizer after switching to CRD /status sub-resource (#8) * Add tests to webhooks (#11) * Replace changevalidator with webhook (#14) * Replace default service plan with webhook (#10) * Add tests to webhooks - fix * Rewrite defaultServicePlan feature to webhook * Replace plugins by webhook (#16) * Replace ServiceBinding plugin by webhook * Replace Broker plugins by webhook * Adjust webhooks to multi validation handlers * Service Catalog going towards to CRDs (#18) * Migrate registry/strategy Updates to webhooks (#17) * Use Update instead of updateReference method (#19) * Replace tableconvertor with APC (#20) * Fix svcat tests after the rebase with the upstream master branch * Pre delete jobs - remove CRD after delete helm release (#21) * Apply fixes after executing `make verify` * Create docs about webhook implementation (#24) * Change the securePort for the webhook server because colidates with old api-server * Change import paths to kubernetes-sigs, and rebase with master * Apply fixes after rebase Fixes: * makefile targets, * instance deprovision operation * entries under additionalPrinterColumns in crds.yaml * unit tests after rebase * Update documentation (#40) * Update docs * Fix vendor after rebase with k8s 1.15 bump * Apply changes after review - remove the contrib/hack/crd folder - remove reference to Kyma project - rebase with current master - restore the image in chart - extract CRDs defintion to dedicated folder
I wanted to put in an extended user story to tie together the various use cases and create some customer empathy.
Please let me know what you think. Thanks in advance for the feedback.