-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jerry,
> On 7/19/19 13:38, Jerry Malcolm wrote: >>>> I have had a dedicated hosted environment with WAMP and >>>> Tomcat for over 15 years. I'm very familiar with everything >>>> related to that environment... apache http, mysql, dns >>>> server, the file system, JAMES, and all of my management >>>> scripts that I've accumulated over the years. Everything is >>>> in the same box and basically on the same desktop. But now I >>>> have a client that has needs that are best met in an AWS >>>> environment. > Can you explain that in a little more depth? What is it about AWS > that meets their needs better? > > I ask because you can provision a one-box wonder in AWS just like > you do on a physical space with a single server. You just have to > use remote-desktop to get into it, and then it's all the same. > > But if they want to use RDS, auto-scaling, and other > Amazon-provided services then things can get confusing. >> Unfortunately, that is the precise reason we need to go AWS.... >> Extremely high availability and scalability / load-balancing >> across multiple instances. There will need to at least one >> instance running at all times. Even when doing >> maintenance/upgrades on other instances. It's not "unfortunate" necessarily. At least it makes it clear why they want to migrate to AWS. > So the answer to your question really depends upon what the client > thinks they'll be getting by you taking your existing product "to > the cloud". > >>>> I understand just enough AWS to be dangerous, which is not >>>> much.... I do know that it's a bunch of different modules, >>>> and I believe I lose the direct file system access. > That heavily depends upon how you do things. You can get yourself > a server with a disk and everything, just like you are used to > doing. >> Do you mean AWS offers a 'file server' module that I can >> basically access directly as a drive from TC? If so, that eases >> my mind a bunch. I manage and serve gigabytes of videos and >> photos. I don't really want a full CMS implementation. Just >> want a big hard drive I can get to. No, AWS doesn't really have a "file server" module that you can enable. Do you need a large disk for bulk storage? What are you storing? Perhaps switching over to a key-value store (which can act like a filesystem) or a document-store database (e.g. CouchDB) if you have fairly regular documents that you want to store. All of those technologies are quite cloud-friendly. You can even use them single-node if you want to make your application available to either AWS-based clients OR your more traditional one-box-wonder clients. Or, you can abstract your "write a file somewhere" process so that you can swap implementations at run-time: configuration says local-disk? Use FileWriter. Using CouchDB? Push the file to CouchDB through it's APIs. >>>> I've watched an AWS intro video and a couple of youtube >>>> videos on setting up TC in AWS. But they always starts with >>>> "now that you have your AWS environment set up....". I am >>>> looking for something that explains the big picture of >>>> migrating an existing WAMP+TC to AWS. I am not so naive to >>>> think that there won't be significant rip-up to what I have >>>> now. But I don't want to do unnecessary rip-up just because I >>>> don't understand where I'm heading. Basically, I don't know >>>> enough to know what I don't know.... But I need to start >>>> planning ahead and learning soon if I'm going to have any >>>> disasters in my code where I might have played it too loose >>>> with accessing the file system directly in my dedicated >>>> environment. >>>> >>>> Has anyone been down this path before and could point me to >>>> some tutorials targeted to migrating WAMP+TC to AWS? Or >>>> possible hand-hold me just a little...? I'm a pretty quick >>>> learner. I just don't know where to start. > As usual, start with your requirements :) > >> Requirements are what I have now in a single box, but with the >> addition of multiple instances of TC (and HTTPD and/or mySQL?) >> for HA and load balancing. One box with multi is ... not HA. Sorry. That allows you to do things like upgrade the application without taking it down completely. But it does not allow you to perform maintenance on the OS because everything has to come down. >> Day-1 launch won't be massive traffic and theoretically could be >> handled by my single dedicated server I have today. But if this >> takes off like the client predicts, I don't want to get caught >> flat-footed and have to throw together an emergency redesign to >> begin clustering TC to handle the traffic. Rather go live >> initially with single instance AWS, but with a thought-out (and >> tested/verified) plan to easily begin clustering when the need >> hits. One of the first things I'd take a look at is what it would take to switch from vanilla MySQL to one of the databases available through RDS. This sounds stupid: MySQL is available via RDS, so you're done, right? Well, it's not so simple. First of all, RDS is distributed by definition. So anything that affects e.g. MySQL when you go "distributed" means that your application has to handle it. For example -- and we're doing this right now with MariaDB -- when you program a simple JDBC transaction, you usually expect that an INSERT is going to fail if a record with the same PK already exists, and then you roll-back that transaction and you are done. The user has to try again maybe. You don't like that, so you do this: BEGIN SELECT id, foo, bar, baz FROM table WHERE id=? FOR UPDATE if(present) update row with new foo, bar, baz values update row else move to insert row update row with new foo, bar, baz values insert row COMMIT That's great, and it works perfectly on a single server. However, on multiple servers, you can get a failure on COMMIT because that's when the transaction is sent-around to the rest of the cluster. So if you want to have semantics like the above (create-or-update record), then you have to wrap pretty much every transaction in a "try it once; if you fail, rollback and try the exact same thing again". You need to do this because if you don't, you'll give your users way more unnecessary errors because simply re-trying the transaction will (likely) succeed because the contention has passed. I'm assuming that there isn't anything problematic about running multiple web application instances because you said you already run multi-instance. Don't run those on the same EC2 instance. Instead, run multiple EC2 instances. Load-balancing is easy, although I have to admit that I haven't figured out yet how to properly do "application load balancers" (I use old-school "Classic" ELB). Once you can (a) use ELB (b) have multiple EC2 instances for your applications and (c) use RDS, I think you'll be able to go into production like that and figure everything else out from there. I've really been hoping that someone can come to an ApacheCon and give a presentation about deploying Tomcat-based web applications to AWS. Especially talking about auto-scaling and stuff like that. Jean-Frederic has been showing his "to the cloud" presentation but it's not nearly to the level of detail that I'd like to see. Yes, I can see that he has been able to do it, but I have no idea HOW it has been done. What is the role of e.g. Kubernetes? How does one provision those services to get started? What do you need to start with one node? How do you move to 2 nodes? What about arbitrary auto-scaling with AWS? These are the kinds of things I want to see. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0zFNAACgkQHPApP6U8 pFi6aBAAjaa3dxJqf05te+3FU8m96nVoy1uNwmRo9bho3/I9mnqgSfnhaVRK/hoj iDY5liszC41nT30r+1cJLl3W59PECGS0oPWU3f8G7nI3F9gg7g3NcE1GvawiIzsx Y4iklZ7Cz3w54v3oqq3JcWKDoPL94BFl513+7HwIIKv6qVARrzQI+6YONG6pw1Or kgi1j9CrS8sZKL1MLCDPcGkCID+nw/WdlNtVsYRwJsgLELH9YwL2HKBqZ+nQDWhW 4jwzNogzzWbKYFSVbbDRYiW7f5os/YrDs8QXFGBM8fYyNJIC7R5v/tf0qiojxm6t smWfiY6W4VM14cCCaM1kcRw5YUpO9E3o5ZXrSlNtCbG9qdi+wCMmYdbdVyBpPc2d m1wN/BI9QEWNNPaUlVO8Fr6zw+pyrt1AW6HUYs/k7juhy6PjucGD7+iDAI1Xgzkc XTrIz0aCvnGIkfrbDi4ERz3l41xZq1sOMd0yAQJf/S/RpQphGGNxZFItxs7aj6PN g+u8nsMnK///Z2ky6qAV2sHBKeQ9PxYqr1fuwQgisUxuFXDO/Alfg7TNc04/iuGq JwGloJ81wtngpM8e3hpWqOQH51j79Fk/Gb0Sql5SVxZvwxec5Gm8LZe0f86ONpLI 3yAgFiq2uaOuteHxptZtJcFdgMrqMQ0iOvRstXg0w60uqgNfRA0= =SorY -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
