Re: Java Cro 2022 conclusions

[Geoff Macartney]

Thanks Iuliana,

I'll have a look at the repo. It's great that you are presenting
Apache Brooklyn like this. Do let us know on the list if you are doing
any more in the future!

Best regards
Geoff


On Fri, 14 Oct 2022 at 19:11, Iuliana Cosmina  wrote:
>
> Hello Geoff,
>
> Unfortunately the conference was not recorded, and I was not prepared to do
> my own recording. The whole event seems to be big in Croatia, but I've
> found the overall organization and promotion of the event was pretty...
> lacking. Hopefully it will get better in the future.
>
> The Brooklyn Terraform module is the one started from Cloudsoft, it is
> open-source so anybody can contribute. I used it because it provided me a
> way to make the Brooklyn types as generic as possible.
>
> The  code and configuration for the demo, the presentation as well are in
> this repository, in case anybody is interested:
> https://github.com/cloudsoft/java-cro
>
> Best Regards,
> Iuliana Cosmina
>
>
>
>
>
> On Thu, Oct 13, 2022, 15:18 Geoff Macartney  wrote:
>
> > Hi Iuliana,
> >
> > Thanks for the update, this sounds marvellous. Was your presentation
> > recorded? I would love to watch it.
> >
> > Just for clarity, by "the brooklyn-terraform module" I assume you mean
> > Cloudsoft's repo of that name [1]. Of course, since this is open and
> > Apache 2.0 licensed, anyone can contribute to it!
> >
> > Best regards
> > Geoff
> >
> >
> > [1] https://github.com/cloudsoft/brooklyn-terraform
> >
> > On Wed, 12 Oct 2022 at 10:52, Iuliana Cosmina 
> > wrote:
> > >
> > > Hi team,
> > >
> > > This week I participated in a Java conference (
> > > https://2022autumn.javacro.hr/eng) and I demonstrated how Apache
> > Brooklyn
> > > can be used to develop applications for the cloud locally, that get
> > > deployed to little or no change to a cloud provider.  I used the
> > > brooklyn-terraform module to deploy a three tier application to a
> > > local Kubernetes cluster and then migrate it to EKS.
> > >
> > > Here are a few things a few things that we must/should do that I figured
> > > out  while preparing the demo and presenting at #javacro2022:
> > >
> > > 1. When we have a frontend (or anything really) depending on a cluster
> > that
> > > exposes some sensors the frontend needs, deleting the app causes the
> > > dependent component to hang, because the cluster is deleted first. Not
> > sure
> > > if this is caused by the fact that the cluster is a software component,
> > or
> > > maybe we have a race condition between deleting tasks.  I can reproduce
> > it
> > > easily, so this is a bug  that we can and we should fix.
> > > 2. We need to add custom terraform types: dbs, servers,  for  most used
> > > cloud providers etc.
> > > 3. All terraform entities under the same parent  - when deployed on
> > > Kubernetes - should be deployed under the same namespace - it helps with
> > > cleaning. Also.. maybe in the case of an application that had only
> > > terraform entities deployed on the same Kubernetes cluster as children, a
> > > successful deletion of the namespace should suffice and Apache Brooklyn
> > > should back off instead of trying to delete the entities itself and
> > failing
> > > to do so. We could use the power of Kubernetes when possible.
> > > 4. At this conference there were a lot of young people  just dipping
> > their
> > > toes in cloud development and they are interested in Apache Brooklyn for
> > > its ability to help them get used to working on the cloud without an
> > actual
> > > cloud. Maybe a collaboration with Universities for workshops should be
> > > considered. Also we could use some fresh eyes on Brooklyn to get some
> > > feedback, use them as a testing resource and a source of ideas for things
> > > missing in Apache Brooklyn.
> > > 5. When terraform deploys over an unstable network, the application
> > deploy
> > > fails in Brooklyn. Is there anything we can do about this? Maybe a retry?
> > > 6. One observation from a fellow speaker is that in order to get things
> > > done, we need to write a lot of YAML. I don't particularly disagree, nor
> > > have any idea how to fix it, unless we consider trying to enrich our
> > > catalog with out of the box types for most recent technologies.
> > >
> > > That is pretty much it, if anything else comes to mind, I'll make another
> > > list and continue this email thread.
> > >
> > > Observation: You might ask why I used Apache Brooklyn to drive a
> > Terraform
> > > deployment on a Kubernetes cluster? Because it provided me the
> > opportunity
> > > to try to create a CAMP blueprint agnostic towards where it got deployed.
> > >
> > > --
> > >
> > > Best regards,
> > > Iuliana Cosmina
> > >
> > > 
> >

Re: Java Cro 2022 conclusions

[Iuliana Cosmina]

Hello Geoff,

Unfortunately the conference was not recorded, and I was not prepared to do
my own recording. The whole event seems to be big in Croatia, but I've
found the overall organization and promotion of the event was pretty...
lacking. Hopefully it will get better in the future.

The Brooklyn Terraform module is the one started from Cloudsoft, it is
open-source so anybody can contribute. I used it because it provided me a
way to make the Brooklyn types as generic as possible.

The  code and configuration for the demo, the presentation as well are in
this repository, in case anybody is interested:
https://github.com/cloudsoft/java-cro

Best Regards,
Iuliana Cosmina





On Thu, Oct 13, 2022, 15:18 Geoff Macartney  wrote:

> Hi Iuliana,
>
> Thanks for the update, this sounds marvellous. Was your presentation
> recorded? I would love to watch it.
>
> Just for clarity, by "the brooklyn-terraform module" I assume you mean
> Cloudsoft's repo of that name [1]. Of course, since this is open and
> Apache 2.0 licensed, anyone can contribute to it!
>
> Best regards
> Geoff
>
>
> [1] https://github.com/cloudsoft/brooklyn-terraform
>
> On Wed, 12 Oct 2022 at 10:52, Iuliana Cosmina 
> wrote:
> >
> > Hi team,
> >
> > This week I participated in a Java conference (
> > https://2022autumn.javacro.hr/eng) and I demonstrated how Apache
> Brooklyn
> > can be used to develop applications for the cloud locally, that get
> > deployed to little or no change to a cloud provider.  I used the
> > brooklyn-terraform module to deploy a three tier application to a
> > local Kubernetes cluster and then migrate it to EKS.
> >
> > Here are a few things a few things that we must/should do that I figured
> > out  while preparing the demo and presenting at #javacro2022:
> >
> > 1. When we have a frontend (or anything really) depending on a cluster
> that
> > exposes some sensors the frontend needs, deleting the app causes the
> > dependent component to hang, because the cluster is deleted first. Not
> sure
> > if this is caused by the fact that the cluster is a software component,
> or
> > maybe we have a race condition between deleting tasks.  I can reproduce
> it
> > easily, so this is a bug  that we can and we should fix.
> > 2. We need to add custom terraform types: dbs, servers,  for  most used
> > cloud providers etc.
> > 3. All terraform entities under the same parent  - when deployed on
> > Kubernetes - should be deployed under the same namespace - it helps with
> > cleaning. Also.. maybe in the case of an application that had only
> > terraform entities deployed on the same Kubernetes cluster as children, a
> > successful deletion of the namespace should suffice and Apache Brooklyn
> > should back off instead of trying to delete the entities itself and
> failing
> > to do so. We could use the power of Kubernetes when possible.
> > 4. At this conference there were a lot of young people  just dipping
> their
> > toes in cloud development and they are interested in Apache Brooklyn for
> > its ability to help them get used to working on the cloud without an
> actual
> > cloud. Maybe a collaboration with Universities for workshops should be
> > considered. Also we could use some fresh eyes on Brooklyn to get some
> > feedback, use them as a testing resource and a source of ideas for things
> > missing in Apache Brooklyn.
> > 5. When terraform deploys over an unstable network, the application
> deploy
> > fails in Brooklyn. Is there anything we can do about this? Maybe a retry?
> > 6. One observation from a fellow speaker is that in order to get things
> > done, we need to write a lot of YAML. I don't particularly disagree, nor
> > have any idea how to fix it, unless we consider trying to enrich our
> > catalog with out of the box types for most recent technologies.
> >
> > That is pretty much it, if anything else comes to mind, I'll make another
> > list and continue this email thread.
> >
> > Observation: You might ask why I used Apache Brooklyn to drive a
> Terraform
> > deployment on a Kubernetes cluster? Because it provided me the
> opportunity
> > to try to create a CAMP blueprint agnostic towards where it got deployed.
> >
> > --
> >
> > Best regards,
> > Iuliana Cosmina
> >
> > 
>

Re: Java Cro 2022 conclusions

[Geoff Macartney]

Hi Iuliana,

Thanks for the update, this sounds marvellous. Was your presentation
recorded? I would love to watch it.

Just for clarity, by "the brooklyn-terraform module" I assume you mean
Cloudsoft's repo of that name [1]. Of course, since this is open and
Apache 2.0 licensed, anyone can contribute to it!

Best regards
Geoff


[1] https://github.com/cloudsoft/brooklyn-terraform

On Wed, 12 Oct 2022 at 10:52, Iuliana Cosmina  wrote:
>
> Hi team,
>
> This week I participated in a Java conference (
> https://2022autumn.javacro.hr/eng) and I demonstrated how Apache Brooklyn
> can be used to develop applications for the cloud locally, that get
> deployed to little or no change to a cloud provider.  I used the
> brooklyn-terraform module to deploy a three tier application to a
> local Kubernetes cluster and then migrate it to EKS.
>
> Here are a few things a few things that we must/should do that I figured
> out  while preparing the demo and presenting at #javacro2022:
>
> 1. When we have a frontend (or anything really) depending on a cluster that
> exposes some sensors the frontend needs, deleting the app causes the
> dependent component to hang, because the cluster is deleted first. Not sure
> if this is caused by the fact that the cluster is a software component, or
> maybe we have a race condition between deleting tasks.  I can reproduce it
> easily, so this is a bug  that we can and we should fix.
> 2. We need to add custom terraform types: dbs, servers,  for  most used
> cloud providers etc.
> 3. All terraform entities under the same parent  - when deployed on
> Kubernetes - should be deployed under the same namespace - it helps with
> cleaning. Also.. maybe in the case of an application that had only
> terraform entities deployed on the same Kubernetes cluster as children, a
> successful deletion of the namespace should suffice and Apache Brooklyn
> should back off instead of trying to delete the entities itself and failing
> to do so. We could use the power of Kubernetes when possible.
> 4. At this conference there were a lot of young people  just dipping their
> toes in cloud development and they are interested in Apache Brooklyn for
> its ability to help them get used to working on the cloud without an actual
> cloud. Maybe a collaboration with Universities for workshops should be
> considered. Also we could use some fresh eyes on Brooklyn to get some
> feedback, use them as a testing resource and a source of ideas for things
> missing in Apache Brooklyn.
> 5. When terraform deploys over an unstable network, the application deploy
> fails in Brooklyn. Is there anything we can do about this? Maybe a retry?
> 6. One observation from a fellow speaker is that in order to get things
> done, we need to write a lot of YAML. I don't particularly disagree, nor
> have any idea how to fix it, unless we consider trying to enrich our
> catalog with out of the box types for most recent technologies.
>
> That is pretty much it, if anything else comes to mind, I'll make another
> list and continue this email thread.
>
> Observation: You might ask why I used Apache Brooklyn to drive a Terraform
> deployment on a Kubernetes cluster? Because it provided me the opportunity
> to try to create a CAMP blueprint agnostic towards where it got deployed.
>
> --
>
> Best regards,
> Iuliana Cosmina
>
> 

Java Cro 2022 conclusions

[Iuliana Cosmina]

Hi team,

This week I participated in a Java conference (
https://2022autumn.javacro.hr/eng) and I demonstrated how Apache Brooklyn
can be used to develop applications for the cloud locally, that get
deployed to little or no change to a cloud provider.  I used the
brooklyn-terraform module to deploy a three tier application to a
local Kubernetes cluster and then migrate it to EKS.

Here are a few things a few things that we must/should do that I figured
out  while preparing the demo and presenting at #javacro2022:

1. When we have a frontend (or anything really) depending on a cluster that
exposes some sensors the frontend needs, deleting the app causes the
dependent component to hang, because the cluster is deleted first. Not sure
if this is caused by the fact that the cluster is a software component, or
maybe we have a race condition between deleting tasks.  I can reproduce it
easily, so this is a bug  that we can and we should fix.
2. We need to add custom terraform types: dbs, servers,  for  most used
cloud providers etc.
3. All terraform entities under the same parent  - when deployed on
Kubernetes - should be deployed under the same namespace - it helps with
cleaning. Also.. maybe in the case of an application that had only
terraform entities deployed on the same Kubernetes cluster as children, a
successful deletion of the namespace should suffice and Apache Brooklyn
should back off instead of trying to delete the entities itself and failing
to do so. We could use the power of Kubernetes when possible.
4. At this conference there were a lot of young people  just dipping their
toes in cloud development and they are interested in Apache Brooklyn for
its ability to help them get used to working on the cloud without an actual
cloud. Maybe a collaboration with Universities for workshops should be
considered. Also we could use some fresh eyes on Brooklyn to get some
feedback, use them as a testing resource and a source of ideas for things
missing in Apache Brooklyn.
5. When terraform deploys over an unstable network, the application deploy
fails in Brooklyn. Is there anything we can do about this? Maybe a retry?
6. One observation from a fellow speaker is that in order to get things
done, we need to write a lot of YAML. I don't particularly disagree, nor
have any idea how to fix it, unless we consider trying to enrich our
catalog with out of the box types for most recent technologies.

That is pretty much it, if anything else comes to mind, I'll make another
list and continue this email thread.

Observation: You might ask why I used Apache Brooklyn to drive a Terraform
deployment on a Kubernetes cluster? Because it provided me the opportunity
to try to create a CAMP blueprint agnostic towards where it got deployed.

-- 

Best regards,
Iuliana Cosmina