News

Soundbyte 55: Cryin' Like A Bitch

5 augustus 2012

Polyglot Fighting
When someone asks what music I like I often answer “whatever music with lots of guitars in it”. Of course that’s not entirely true, but my musical taste does range from old blues to modern heavy metal; from BB King to Gov’t Mule and Deep Purple to Godsmack. While going though this range of music to select something for the Soundbyte I found something that actually combines two things I like: Guitars and Fighting…. This is Godsmack with “Cryin’ Like A Bitch”.

The video clip shows shots from UFC fights; the world’s highest league for mixed martial arts. The interesting thing about this sport is how fast it evolved in the past ten years, and how extremely technical it is. Ten years ago you where either a striker or a wrestler, and “mixed” basically meant that you could be fighting guys having a different style. Today this would leave you nowhere; the only way to compete is to understand and excel at the whole game.

This is not so different from the evolution we are seeing in software development in the past few years. Being a “SQL guy” or “backend developer” doesn’t really cut it any more. We are now talking about polyglot development with polyglot persistence and a wide range of frameworks and related technologies. Combining Java with scripting languages like Groovy and Ruby and of course JavaScript in the browser, and combining several types of data stores. With the cloud developers also need to know a lot about their infrastructure to make fully use of it. Choosing the right tool for the job is key and starts by learning that there are actually a lot of different hammers and nails 😉

Being quicker then the other guy
In a week where the rest of the world tries to figure out who can run and swim the fastest I had a very interesting discussion with Bert Ertman about whether you can or cannot develop as fast with a Java stack as you can with Ruby on Rails or PHP. Of course we have to be careful to compare apples to apples; we are talking about large, long-term projects where quality and maintainability are important. Having used a lot of PHP in the past and worked on several Grails projects I actually strongly believe that a modern Java stack is at least as productive as any of the alternatives. Java has made a name of being unproductive and complex. We probably have technology such as Websphere Portal Server to thank for this, but hopefully we all agree that this is not the way it’s supposed to be. Looking at modern Java stacks such as Java EE 6 or, even better, a modular OSGi stack with Amdatu we really have competitive development stacks. Take a look at BndTools for example. It gives you hot updates of code changes in a running application. We can run in-container integration tests straight from the IDE and Java EE and Amdatu make it trivial to write RESTful web services and use technology such as MongoDB. Of course you can still argue that the Java language is verbose compared to scripting languages and this is absolutely true. Scripting languages require a lot more tests however because it’s easier to make typos and there is a lot less refactoring support in tooling. Once again it’s about choosing the right tool for the job. In Leren-op-Maat we use Java for most of the code, because it’s most easy to maintain at large scale. We also use Groovy at several places however because the code required to solve a specific problem just fits a scripting language better.

Leren-op-Maat 1.0
Last week I tagged the official Leren-op-Maat 1.0 version. While the past year definitely wasn’t easy we managed to finish the release well before the deadline of the new school year. Of course Leren-op-Maat is not “finished”; there are still a lot of ideas we will work on for next releases, but the 1.0 release is ready to be used in the new school year starting end of this month. Several schools will start using the concept of personalized learning. We are setting things in motion…

Besides the software there is a whole team of people working on the non-technical side of Leren-op-Maat. Content is being processed and teachers are trained in the idea of personalized learning. It’s going to be very exiting to see how it’s going to go from here.

In the past few weeks I have been focussed on load testing and performance tuning to decide what kind of servers we need for a given amount of students using the system. We are taking this a step further and will use fully automated scaling. Leren-op-Maat runs on the Amazon cloud (but we could use other providers). Amazon EC2 is Infrastructure-As-A-Service; you basically just rent (virtual) hardware. The first benefit is that you can turn on and turn of servers whenever you like. This doesn’t give automated scaling yet however, because with automated scaling you don’t want any downtime, and adding and removing server instances should be automated. For Leren-op-Maat we implemented this as follows. Each school runs in it’s own cluster. Each cluster starts with a load balancer. Load balancers are an AWS feature, you can configure this using the AWS tooling. For each cluster we use AWS Auto Scaling configuration to start up the actual server instances. With this configuration you define the minimum and maximum amount and type of server instances that should be part of the cluster. When a new server is started it will register itself to the load balancer automatically. You can define all kind of triggers when new machines should be added or machines should be removed such as number of requests, CPU load of instances, scheduled triggers etc.
Starting empty servers doesn’t really help much of course, we have to find a way to deploy our software on it. This can’t be a static deployment, because we should keep it simple to apply updates on the software, and each school uses slightly different configuration and artifacts. We solve this by running a script at instance startup that uses the Apache ACE REST API to register itself as a new target and request a distribution to be installed. Whenever we update bundles in ACE, all servers will still be updated automatically.

This slightly complex infrastructure has the benefit that we can handle very high loads, while only paying for the servers when we actually need them. This fits our situation very well where more students will be online during school hours then during their free time.

Amdatu.org
As you probably know Amdatu Platform 1.0 was released a few months ago. We are now working hard to make it easier to actually get started using Amdatu and modularity in general. While not completely final yet, you can already get a sneak peek at the completely new amdatu.org website. It now contains video tutorials and getting started documentation that show how to start using OSGi and Amdatu and deploy to the cloud using Apache ACE. Let us know if there is anything missing or unclear. In the next few months we will continue to work on this and we will have plenty of coverage on conferences in the next few months.

You might also have heard the news that Jigsaw will probably not be part of Java 8. This makes our focus on modularity even more relevant. Software must be able to adapt and change more quickly and the cloud demands more flexible deployment scenarios. Modularity is key to write maintainable software while having these requirements.
Sorry, dit bericht is er alleen in het English

Polyglot Fighting
When someone asks what music I like I often answer “whatever music with lots of guitars in it”. Of course that’s not entirely true, but my musical taste does range from old blues to modern heavy metal; from BB King to Gov’t Mule and Deep Purple to Godsmack. While going though this range of music to select something for the Soundbyte I found something that actually combines two things I like: Guitars and Fighting…. This is Godsmack with “Cryin’ Like A Bitch”.

The video clip shows shots from UFC fights; the world’s highest league for mixed martial arts. The interesting thing about this sport is how fast it evolved in the past ten years, and how extremely technical it is. Ten years ago you where either a striker or a wrestler, and “mixed” basically meant that you could be fighting guys having a different style. Today this would leave you nowhere; the only way to compete is to understand and excel at the whole game.

This is not so different from the evolution we are seeing in software development in the past few years. Being a “SQL guy” or “backend developer” doesn’t really cut it any more. We are now talking about polyglot development with polyglot persistence and a wide range of frameworks and related technologies. Combining Java with scripting languages like Groovy and Ruby and of course JavaScript in the browser, and combining several types of data stores. With the cloud developers also need to know a lot about their infrastructure to make fully use of it. Choosing the right tool for the job is key and starts by learning that there are actually a lot of different hammers and nails 😉

Being quicker then the other guy
In a week where the rest of the world tries to figure out who can run and swim the fastest I had a very interesting discussion with Bert Ertman about whether you can or cannot develop as fast with a Java stack as you can with Ruby on Rails or PHP. Of course we have to be careful to compare apples to apples; we are talking about large, long-term projects where quality and maintainability are important. Having used a lot of PHP in the past and worked on several Grails projects I actually strongly believe that a modern Java stack is at least as productive as any of the alternatives. Java has made a name of being unproductive and complex. We probably have technology such as Websphere Portal Server to thank for this, but hopefully we all agree that this is not the way it’s supposed to be. Looking at modern Java stacks such as Java EE 6 or, even better, a modular OSGi stack with Amdatu we really have competitive development stacks. Take a look at BndTools for example. It gives you hot updates of code changes in a running application. We can run in-container integration tests straight from the IDE and Java EE and Amdatu make it trivial to write RESTful web services and use technology such as MongoDB. Of course you can still argue that the Java language is verbose compared to scripting languages and this is absolutely true. Scripting languages require a lot more tests however because it’s easier to make typos and there is a lot less refactoring support in tooling. Once again it’s about choosing the right tool for the job. In Leren-op-Maat we use Java for most of the code, because it’s most easy to maintain at large scale. We also use Groovy at several places however because the code required to solve a specific problem just fits a scripting language better.

Leren-op-Maat 1.0
Last week I tagged the official Leren-op-Maat 1.0 version. While the past year definitely wasn’t easy we managed to finish the release well before the deadline of the new school year. Of course Leren-op-Maat is not “finished”; there are still a lot of ideas we will work on for next releases, but the 1.0 release is ready to be used in the new school year starting end of this month. Several schools will start using the concept of personalized learning. We are setting things in motion…

Besides the software there is a whole team of people working on the non-technical side of Leren-op-Maat. Content is being processed and teachers are trained in the idea of personalized learning. It’s going to be very exiting to see how it’s going to go from here.

In the past few weeks I have been focussed on load testing and performance tuning to decide what kind of servers we need for a given amount of students using the system. We are taking this a step further and will use fully automated scaling. Leren-op-Maat runs on the Amazon cloud (but we could use other providers). Amazon EC2 is Infrastructure-As-A-Service; you basically just rent (virtual) hardware. The first benefit is that you can turn on and turn of servers whenever you like. This doesn’t give automated scaling yet however, because with automated scaling you don’t want any downtime, and adding and removing server instances should be automated. For Leren-op-Maat we implemented this as follows. Each school runs in it’s own cluster. Each cluster starts with a load balancer. Load balancers are an AWS feature, you can configure this using the AWS tooling. For each cluster we use AWS Auto Scaling configuration to start up the actual server instances. With this configuration you define the minimum and maximum amount and type of server instances that should be part of the cluster. When a new server is started it will register itself to the load balancer automatically. You can define all kind of triggers when new machines should be added or machines should be removed such as number of requests, CPU load of instances, scheduled triggers etc.
Starting empty servers doesn’t really help much of course, we have to find a way to deploy our software on it. This can’t be a static deployment, because we should keep it simple to apply updates on the software, and each school uses slightly different configuration and artifacts. We solve this by running a script at instance startup that uses the Apache ACE REST API to register itself as a new target and request a distribution to be installed. Whenever we update bundles in ACE, all servers will still be updated automatically.

This slightly complex infrastructure has the benefit that we can handle very high loads, while only paying for the servers when we actually need them. This fits our situation very well where more students will be online during school hours then during their free time.

Amdatu.org
As you probably know Amdatu Platform 1.0 was released a few months ago. We are now working hard to make it easier to actually get started using Amdatu and modularity in general. While not completely final yet, you can already get a sneak peek at the completely new amdatu.org website. It now contains video tutorials and getting started documentation that show how to start using OSGi and Amdatu and deploy to the cloud using Apache ACE. Let us know if there is anything missing or unclear. In the next few months we will continue to work on this and we will have plenty of coverage on conferences in the next few months.

You might also have heard the news that Jigsaw will probably not be part of Java 8. This makes our focus on modularity even more relevant. Software must be able to adapt and change more quickly and the cloud demands more flexible deployment scenarios. Modularity is key to write maintainable software while having these requirements.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *