This week's book giveaway is in the Java in General forum.
We're giving away four copies of Event Streams in Action and have Alexander Dean & Valentin Crettaz on-line!
See this thread for details.
Win a copy of Event Streams in Action this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Cloud Native Patterns - pitfalls?

 
Ranch Hand
Posts: 396
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
What are the mistakes people make when developing a web app that will be hosted on the cloud?
thanks,
Paul
 
Author
Posts: 7
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul.

There are many - I'll name but a few here.
  • Using sticky sessions: Sticky sessions encourage the load balancer to route multiple requests to the same application instance and it's a pattern we used for a long time in web applications. And it worked okay when we had application instances that stayed alive for extended periods of time. But these days, app instances (most often running in containers) live much shorter lives and the chances of an instance being there from one user request to their next goes down significantly. I cover sticky sessions in some depth in section 5.3.
  • Putting application configurations into property files. "What?!?!" you say? "Aren't property files a best practice? It's better than hard coding in the code!" - Yes, property files ARE a best practice, but because they are often compiled into the binary, that means a config change requires a new build. This causes all sorts of downstream production deploy problems. Instead of putting the values in the property file, I suggest using it (the prop file) to list the variables that need to be bound and using a configuration server to manage the values. I cover this in a great deal of depth in chapter 6.
  • Assuming because they have multiple instances of an app and have deployed to a platform like Kubernetes that their app will work through a rolling upgrade. Have a look at the example on credential rotation in sections 7.2 and 7.3 (the chapter on application lifecycle - I cover rolling upgrades and blue/green upgrades in there).


  • There are many more covered in the book.

    Cornelia
     
    paul nisset
    Ranch Hand
    Posts: 396
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Cornelia.
    The concept of a configuration server is interesting . We were recently asked to provide an alternative to properties files on our systems . There was a concern with the security in using them and all the database credentials for a web app being in a single plain text file. I didn't think hardcoding them was a good alternative or even that more secure in the case of reverse engineering.

    The book sounds like it has some excellent practical advice.
    -Paul
     
    Sheriff
    Posts: 4648
    300
    IntelliJ IDE Clojure Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    As it happens I have recently implemented what Cornelia discusses for configuration files for the same reasons. Property files were being bundled up in the jar (it's a Java app) so the build was directly coupled to the configuration. Also we had sensitive configuration in plain text files, such as database credentials, email server credentials, Stripe payment gateway credentials (eek!).

    I got the idea from Michael T Nygard's "Release it!" book, which is a terrifyingly excellent read and highly recommended. (I say terrifyingly excellent because it makes you realise how under prepared your application is for the production environment.)

    We already use Amazon AWS for a bunch of other services so it was a natural fit to make use of their Parameter Store offering to keep our application configuration in. There was some code changes required to retrieve the properties and add them to the environment but it turned out to be not that hard because the AWS Java SDK does most of the heavy lifting for you.
     
    paul nisset
    Ranch Hand
    Posts: 396
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you for sharing your experiences Tim .

    Your previous situation is exactly what we have.

    Property files were being bundled up in the jar


    We are in the process of migrating some of our web apps to Amazon so Parameter Store is a great tip!  

    Cheers,
    Paul
     
    Marshal
    Posts: 6970
    471
    Mac OS X VI Editor BSD Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Cornelia Davis wrote:Putting application configurations into property files. "What?!?!" you say? "Aren't property files a best practice? It's better than hard coding in the code!" - Yes, property files ARE a best practice, but because they are often compiled into the binary, that means a config change requires a new build.


    Well, another possibility is to have them stored at cloud provider bucket(s), which have restriction policies in place who could operate with them (write, read...), for instance some compute machine's service account on which let's say cloud functions (google) run, same isn't rare to configure some services running on kubernetes pods on the same cloud environment. But I'd agree that bundle properties files with application itself is something what goes off perhaps bit by bit.
     
    Bartender
    Posts: 20928
    127
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Actually, property configuration files compiled into an application (web or otherwise) is a horrible practice.

    I have a very firm policy that I should be able use the exact same byte-for-byte binary components for local development, testing, and production. I cannot do this, if the binary has to be custom built for each environment, I prefer a single binary, because when things go wrong, I don't have to worry about whether my diagnostic processes are being obscured by possible code differences and there's no danger that the wrong version can be deployed to the wrong servers. Which is bad enough when production tries to run on test data, but even worse if you're in a more casual shop and production gets in the hands of developers. Seen that too often.

    As it happens, there's a very useful configuration server built into every J2EE and JEE webapp server, fully supported by the standards: JNDI. This is an excellent place to squirrel essential configuration information such as data file locations, secondary server URLs, locations of extended config data for complex apps and so forth.

    J2EE defines 2 configurations for every webapp. One is server-independent, the other is server-dependent. Everyone knows the server-independent configuration file - it's /WEB-INF/web.xml. The server-independent configuration may or may not be in a file, although many webapp servers do support a file option. For Tomcat, that server-dependent config file is the context.xml file and it can be located within the WAR's /META-INF directory (not recommended for production). as a file with the same name as the webapp context in TOMCAT_HOME/conf/Catalina/localhost (or variants thereof), or implicitly constructed when you dump a raw WAR file or exploded WAR into the TOMCAT_HOME/webapps directory.

    The context.xml file and its equivalents on other webapp server platforms defines the JDBC Connection Pools - assuming that they're not simply inherited from a higher level configuration - and the environment entries (NOTE: Do not attempt to reference OS environment variables in a webapp!). These are the values defined in the web.xml <env-entries> element and can be overridden by the context.xml (or equivalent). They are accessed, as I said, via JNDI (java:comp/env/).

    A consequence of this is that you cannot deploy a webapp simply by plopping a WAR directly into Tomcat (or whatever your preferred webapp server is), since you also need to provision the server-dependent deployment descriptor. My generally preferred way to do this is to package both WAR, deployment descriptor and possibly other related WAR externalities using OS native packaging where the stock OS provisioning managers can handle it. This can be facilitated by, for example, the maven "rpm" plugin when building deployables for Red Hat distros. Or if you prefer, a build control system like Jenkins can do it. Or, if you're building Docker containers, you can just make that a step in the Dockerfile. Or, you can use the server's deployment API. Et cetera.
     
    Cornelia Davis
    Author
    Posts: 7
    6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Holloway wrote: Actually, property configuration files compiled into an application (web or otherwise) is a horrible practice.



    100% agree, but as you can see from the dialog above, it is still quite common to do just that. That is precisely why I cover external configuration in the book. JNDI is a possible implementation of the pattern that I describe - which we might call external configuration. Love your practices Tim.
     
    Tim Holloway
    Bartender
    Posts: 20928
    127
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Cornelia Davis wrote:Love your practices Tim.



    I've had a long and evil career. I learned long ago to make stuff as idiot-proof as possible. Especially from when I'm the idiot it needs to be proof against.
     
    paul nisset
    Ranch Hand
    Posts: 396
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    JNDI and context.xml are excellent for general information like DB server paths etc. But I wouldn't want to put passwords in them.  
    It doesn't really resolve the security of issue  having passwords readily accessible to anyone who has access to the web server having the keys to the kingdom all in one convenient place.

    I've seen people put DB passwords in web.xml (luckily not often). It's quite shocking.    
     
    Tim Holloway
    Bartender
    Posts: 20928
    127
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    paul nisset wrote:JNDI and context.xml are excellent for general information like DB server paths etc. But I wouldn't want to put passwords in them.  
    It doesn't really resolve the security of issue  having passwords readily accessible to anyone who has access to the web server having the keys to the kingdom all in one convenient place.

    I've seen people put DB passwords in web.xml (luckily not often). It's quite shocking.    



    As a rule, however, if someone has access to the server-specific deployment information, they already essentially own the server anyway.

    I'd be glad to hear how you do it, but as far as it goes, most of my deployment info passwords are database passwords, so storing passwords in a database would be problematic - you'd need a password to get a password. So would storing them in LDAP, since you'd need to have the LDAP credentials.

    You're better off using security certs than passwords. The certs can be better secured and generally won't work on any machine but the one they're created for.
     
    paul nisset
    Ranch Hand
    Posts: 396
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Tim.
    It is a bit of a chicken and the  egg syndrome .
    I haven't worked anywhere that has adequately addressed it.

    This is  why I thought Cornelia's suggestions of using Amazon Parameter Store or an external configuration server was interesting .
    Maybe use a cert  to have the web server authenticate to the external configuration server.


    You are right ,if you have a bad actor with access to the web server ,you are in a world of hurt anyway but ( hopefully ) you can minimize it by making it harder to access stored data .
     
    Tim Holloway
    Bartender
    Posts: 20928
    127
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Incidentally, many databases (like PostgreSQL and MySQL) will not accept a valid user ID and password unless it's from an authorized IP. Knowing that the password of the FORT_KNOX database is "swordfish" is of limited use if the only machine that can submit those credentials is locked inside a secure data center where only authorized support personnel can log into it. Stuff things on a VPN and set up decent firewalls, and you're as close to impregnable as IT can be.

    It's worth remembering also that many intrusions aren't due to breaks in basic security, but rather due to insiders doing things they shouldn't or leaking information that they shouldn't. Security is as much about knowing whom to blame if things go wrong as it is about actually locking people out.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!